All of us here in the States have heard horror stories about federal IT fiascos. It's unfortunately not just a federal failing
, since the city and state governments face the same issues, and fail in similar ways. This problem affects quality of service, and costs the taxpayer billions of dollars each year.
It's worth taking a broad-brush look at where we are. Most IT in municipalities, and at the state level, grew up in isolation from the similar systems in other jurisdictions. We have 50 unemployment insurance systems, 50 pension systems, and so on. Multiply these by the municipalities and we are looking at more than 10,000 sets of systems, essentially all doing much the same thing.
When it comes to law enforcement, the problem is compounded, since even small towns run their own shop. Systems don't talk to each other, and there is no central database of crime data in any state. The prisons run independently of the jails, which don't talk to the police, or the courts -- at least online. And talking to the FBI tends to be one-way!
The result is a ramshackle agglomeration of systems that barely work and don't share. The solution looks more like the 1960s than today's mobile universe. We suffer for it.
What can we do to fix this? First, much of the problem results from unrealistic life expectancies for systems. Rumors that tape-based systems are still in use are true, and card decks still load programs, but most systems tend to run 20 or more years. To use the word "antiquated" is a kindness.
Legacy systems are expensive to maintain. There is admittedly no large bubble cost needed to pay for replacement, since the gear is fully paid for, but the software creaks along on low-powered computers using old coding methods, etc. The best analogy is the space shuttle, where the flight computers were of 40-year-old design, and so the astronauts took along notebooks to do the real work.
The problem is we don't have the "notebooks," and so we limp along.
(Source: Shulu Hallak)
We have to address those old systems and move on from legacy code bases. That raises the question of where to go. We can resolve some of the problem expensively by re-writing the legacy code, or getting new mainframes to boost power, but there's a disconnect in that every jurisdiction has to spend to do essentially the same job. The contract software companies would just love that, but the taxpayers would definitely choke on the bill.
This leaves cooperative buying, especially focused on software-as-a-service (SaaS), as the alternative for any real upgrading. Co-ops do exist already, and they use their buying power to leverage better discounts. But they face make-or-buy decisions and there is the risk that we end up with new legacy systems, and pay the price to get there, and to stay there over time, yet again.
What is clearly needed is a SaaS approach. It works for business, and it fits well with cloud computing, and other cost-saving approaches that cities and states are already keen to embrace. However, SaaS has had a mixed reception in government in the US, mainly because it doesn't sit easily with the bidding and contractual process.
Most contracts end up written inflexibly, leading to a make-or-buy decision based on a request for quotation (RFQ) that already selects one or the other up front. Most of these RFQs create an environment for underpricing of initial offers, with expected overruns and specification changes bound to pad the final bill.
To resolve the deadlock requires political action. The US needs to follow the UK in this, where the government mandated that software be purchased from a central App Store. Now, the UK differs from the US in that there is strong central control from the top all the way down to municipalities. Government can make a mandate stick. The result is over $500 million annual savings, and government IT is starting to turn around in the UK.
Cooperative stores focused on IT, similar to other state co-op initiatives, would offer both software and platform services at highly leveraged pricing -- and the available total addressable market would encourage SaaS vendors to offer packages that cover all of the needs for any entity. The question is whether mandates could or should be created and enforced by state or city governments.
This is easier to do where the state provides funds, but would have to appeal to self-interest where it doesn't. One way to help this along is to require independent entities -- like law enforcement agencies -- to tie their systems into new state or city systems, so providing a "stick" to help the carrot of lower costs along. Another is to mandate that SaaS approaches be evaluated -- and audited -- along with "make" alternatives.
The situation is, of course, clouded by politics, lobbying, and resistance to change. Still, nothing succeeds like success, and a couple of pioneer state or municipal authorities showing great results will accelerate the whole process along.