This speech is the keynote for the GovInnovate conference in Canberra on 25 Nov 14. It is a discussion of the topic of sharing ICT infrastructure to enhance public sector efficiency.

Of the various trends in ICT today, two have particular relevance for public sector efficiency. These are cloud computing and shared services. Many commentators and, of course, vendors merge the two, creating a utopian vision in which divestment of responsibilities and reliance on the cloud is the key to CIO success. While this semi-reductionalist approach has its attractions and uses, there are limits.

This presentation will explore the concepts and those limits.

With apologies to the Big Bang Theory, here is the scope of the presentation. In the background, you may have noticed an oscilloscope. Once upon a time, an understanding of electronics at this level was a precursor for understanding computing.

Now, cloud computing has meant that business needs only the most fleeting of understandings of ICT in order to purchase computing services. I think this is a good thing, up to a point. Let's see where that point is.

Roads and public transport are two primary responsibilities of government. Everybody uses roads. A minority use public transport. I see this a a metaphor of sorts for shared infrastructure versus shared services.

The roads provide the infrastructure that everyone can use. They aren't necessarily complex although advanced functions can be more so. They aren't all that hard to join together although if different standards are used, that connectivity can be challenging but it can be overcome. It can be easy to start a simple road, only one lane, not sealed, not even necessarily level. Similarly, a single network can be easy to establish. But, if everyone is building them, efficiency is quickly lost. These common tasks are better done centrally to generate economies of scale and to increase standardisation and reduce costs.

To continue the metaphor, public transport is an application that uses the road infrastructure. There are many other such applications, large and small. Some do the same things in different ways, some do different things in the same way. Some people can afford specialised vehicles or choose to do so. Others look for the cheapest or most efficient alternative and are prepared to travel together.

The use of public transport requires some compromises. One travels according the schedule, sits in an assigned seat, pays for one's ticket, etc. Some advanced vehicles (applications) like aeroplanes (think ERPs) require such specialised handling and maintenance that almost everyone uses them.

However, even at that level, people can go it alone. Sometimes, it takes impositions from above to make people use public transport - think buses to special events. When the purpose is common, the choices are restricted, and/or the price is right, people will use these options.

Thus it is with shared services - sometimes more factors need to align to make them work than is the case for shared infrastructure.

Just because something is difficult, it doesn't mean we shouldn't try to do it. Shared services don't have a great track record in other jurisdictions but there are examples in which they work.

The first class is the common business process situation. Examples are AusTender and APSJobs. These successful applications are used APS wide. Their use is mandated, the governance is not shared, the process is simple, there's no user fee.

Bigger shared services offerings need more than these simple arrangements. Indeed, Gartner suggests that examples like AusTender are 'consolidations' rather than shared services.

Shared services, as defined by Gartner, involve governance of the shared service provider by the customer, payment by the customer, and service levels set through the governance process. It's easy to see why such arrangements require a significant effort to set up, even if the strong leadership, political and organisational, is in place to support them.

Our experience in shared infrastructure is more like the consolidation model. From the initial work in coordinated procurement at one level, through the simple communications link model provided by ICON, to the network infrastructure provided by the Ministerial Communications Network and the National Telepresence System, these examples seek to provide common, relatively simple activities for agencies allowing them to concentrate on the activities that differentiate them rather than those done the same.

I'll consider the latest example, govCMS, in more detail in just a minute.

The Turing test is a test of a machine's ability to exhibit intelligence behaviour equivalent to, or indistinguishable from, that of a human. Sometimes this test is administered by having a test subject interact with the machine through an interface so that the subject doesn't known what is on the other side of the interface. The subject questions the interface to determine whether a human is on the other side.

Why am I raising this? The government's recently announced policy requires agencies to adopt cloud where it is fit for purpose, provides adequate protection of data and delivers value for money. Greater adoption of cloud services will clearly follow as evidenced by demand for such services through offerings such as govCMS.

Vendors are keen to provide such services. Over 110 have applied for inclusion in the current Cloud Services Panel through our recent RFT. This isn't a mandated panel and agencies can purchase services outside it if they so wish.

As part of the assessment of these offerings, vendors were required to demonstrate that they met the NIST definition of cloud services: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

Many of these characteristics are shared by modern managed services. Indeed, on this side of the monitor, how would we tell the difference? Hence, in order to meet government policy, it will be important for us to establish a Turing Test of sorts for cloud computing so that we can be sure we are procuring true cloud services with all the benefits that encompasses.

I don't yet know how such a test will work. But it will be required.

govCMS will open for business broadly on 2 Feb 15. We have already moved australia.gov.au to the new platform and will soon move finance.gov.au. We are working with ASADA as our first external customer and have a range of other agencies queued up to join.

The concept for govCMS grew out of our experience with govSpace, our successful WordPress platform. It provides simple web services, focussed on but not strictly limited to Gov 2.0 activities. It has 55 live sites currently and provides a quick, cheap option to get a website up and running.

govCMS, built on Drupal, provided by Acquia and hosted in the Amazon public cloud, is designed to provide a high quality, cost effective, service for agencies, meeting the security and accessibility requirements of government policy in accordance with the forthcoming digital service standard and design guide.

It isn't mandated but will instead rely for growth on the attractiveness of its business case. It is another of the consolidation instances I referred to earlier.

If we could travel forward in time, I anticipate a significant growth in shared services and shared infrastructure. We can see evidence of this already in various forms - DHS' provision of ICT services to other agencies, through a lead-agency model and the Shared Services Centre already providing services to the Departments of Education and Employment.

Finance's govCMS will continue to grow. We are in the final stages of a scoping study for govDesk and govMail with a view to assisting agencies through the provision of these common services.

We will still need to meet a range of challenges - security, governance, cost efficiency among others. But, building on our successes to date, I am confident that we can.