Is it possible to deliver a government agency’s standard IT systems on a single USB?

CSIR Mk 1 with Hollerith equipment, Sydney 1952 Source: Museum Victoria

The Australian government was one of the earliest adopters of computers and computerisation.

CSIRAC (or CSIR Mk1), the first computer in Australia (and now the oldest surviving first-generation electronic computer), was used by scientists within CSIRO, by the Snowy Mountains Hydro Electric Authority and various university and government departments and agencies between 1949 and 1964 to make sense of ‘big data’ (for the time) which would have taken years to analyse by hand.

As the fifth stored program computer in the world, CSIRAC programmers could write their programs on punch tapes, check them one step at a time, and store them in the computer to be run again and again.

While computers have gotten a lot smaller, faster and efficient, they still use a similar programming approach to CSIRAC. Programs (software) are loaded into their memory and may then be accessed and run many times.

Of course modern computers use different storage mediums and can store and execute many programs at the same time.

Every government agency has an IT architecture made up of hundreds, if not thousands, of different programs – some run on a mainframe computer, others on desktop computers and still more on servers which allow staff to access the programs remotely from their desktop, laptop or even mobile platforms.

It is a very complex process to manage an agency’s IT architecture – some programs may not ‘play nice’ with others, some may be twenty or more years old and require special hardware and maintenance to keep them operating.

Setting up a new agency can be an even more complex process. Often agencies are ‘spawned’ from existing departments and ‘borrow’ much of their IT infrastructure – the software required to run everything from payroll and HR to manage contracts, projects, compliance, Ministerial correspondence and provide the desktop applications required by staff to do their jobs.

Even more complex is the process of combining disparate agencies into a new department. This can require blending two or more sets of software programs into a single solution, with all the data migration and management issues this entails – not to mention addressing security considerations, staff training and avoiding long outages or data loss.

This is where my concept of ‘government on USB’ comes in.

Why not develop all the core software that a government agency needs to operate as open source shareable software and release it for other government agencies to reuse?

Using this approach it is possible that when a government dictates that a new agency must be formed that the CIO simply pulls out his ‘Government Agency USB’ and uploads all the required operational software as a complete agency package.

Potentially, via this method, a new agency could have all its core ICT systems in place and operating in days, if not hours.

This approach might seem farfetched, however we’re already heading in that direction due to a couple of trends.

Today much of the software an agency needs to run its operations is available through SAAS (Software as a Service) or as cloud-based services – which both basically means that software is stored offsite, maintained by a specialist company and simply accessed and used as needed by an agency – provided they are confident of the security levels.

We’re also seeing more and more of the software ‘building blocks’ of organisations becoming available in open source forms which can be downloaded, adjusted as required by an agency and used, either hosted internally or via a SAAS or cloud provided.

The US has actively been developing and releasing software in open source formats for other governments to use, as has the UK and a few other governments around the world. This offers massive national and international efficiencies for governments who can reuse rather than build or buy software.

The next step is for a government to audit the core systems required to establish a new agency and develop a standard IT Architecture that can be applied for any new agency (with room for specialised modules for unique functions). Then, by selecting from existing open source programs and potentially writing additional services, a government could put together a ‘flatpack’ IT architecture that any new agency could adopt quickly and easily.

If all the software in this ‘flatpack’ were open source, it could be easily improved and adjusted over time to meet changing legislative and operational requirements and to integrate ongoing improvements and enhancements.

Then once agencies have adopted this common ‘flatpack’ of software, it would be significantly easier and cheaper to merge agencies, as they would already be operating in a similar and interchangeable way.

Moving all of government across to this approach would take quite a few years – it’s not achievable in a single term – however it would provide ultimately for a ‘government on USB’.

This also has implications across the developing world and for newly formed countries, where their government agencies and institutions can suffer from a lack of experience, expertise and money to build the robust IT architecture needed for modern nations.

In the scenario I’ve described, a new or developing government could simply plug in the ‘government on USB’ into an agency’s systems and establish a sophisticated IT environment to underpin governance in a very short period of time.

Is this simply an unattainable pipedream?

Some may scoff at the notion, however there are many people around the world working on parts of the ‘government on USB’ model today – albeit many may not be thinking about the bigger picture.

Much of the software required for a government agency is already available in open source form, from HR and financial management systems to desktop applications. It simply hasn’t been linked together with a single set-up process.

To explore the concept it would take a government willing to innovate, investing resources and money.

This would be used to model the software requirements of an agency, identify where open source solutions exist (or existing solutions can be modified) and write new open source software where necessary.

Next there would be the need to ensure the solution is secure and to write a single set-up approach that makes it easy for a CIO to roll out the solution quickly.

This may not ultimately be possible or cost-effective, but given the cost of IT architecture changes today when creating, merging or updating agencies, surely it is worth considering.