The idea of developing "Government as a platform" (GaaP) has moved centre stage ahead of the election. The need for open platforms and open APIs was at the heart of the 2010 publication "Better for Less" by Liam Maxwell (now UK Government CTO) - not simply as a technical architecture but as a commercial model too. However, as the recent public "divergence" between GDS and the Crown Commercial Service revealed, there's been a lack of consistency in applying the platform philosophy across both architectural and commercial dimensions within government.
Lessons also need to be learnt from the mistakes of the past. Numerous API-based, open standards components were developed in pre-GDS days for government services such as authentication, payments and transaction handling, but failed to be widely adopted and sustained. As the Government Digital Service (GDS) manual has recognised since 2013, the use of GaaP "does not assume that government has to develop everything in-house: many of government's needs can be met by cost-efficient utility services that already exist. Deciding to develop platforms in-house will happen only where that makes best sense in terms of meeting users' needs in the most flexible and cost-effective way".
A combination of openness and a viable commercial model are essential to establishing successful platforms. The UK has a strong track record in moving towards more open data and open standards in their strategies for modernisation and reform. Less clear however are the incentives that will nurture and sustain the platform model - the usage, commercial and pricing-related mechanisms associated with government in its role as a platform player.
Should government, for example, underwrite the development of core platforms itself on the basis that the longer-term return will ensure it becomes an investment in future public services? This would be an argument for governments to treat platforms as critical national infrastructure, equivalent to public roads and other "common good" investments.
Or does government instead incentivise the market to invest and hence develop platform components through the adoption of, say, a per-transaction model, where intermediaries and third parties are rewarded for delivering services? Or should it adopt a hybrid of both of these approaches – as the GOV.UK Verify identity scheme is doing?
There are also legal boundaries to be considered. Governments often grant themselves exclusive powers to conduct certain functions - for example, the calculation, determination and payment of welfare. But does government require a monopoly on such data processing in the digital age, or should it simply retain a regulatory oversight function? When it comes to other public services, such as PAYE for example, government already leaves employers to do the data processing: why not adopt this same model in other areas too?
Success will require far more than technical engineering alone: moving to government as a platform is not about some simplistic idea of "building things" but represents a radical disruption to the way our public services are conceived, designed, operated and delivered. To succeed and endure, governments first need to understand their true role as a platform player - not simply as an engineer, but as an entrepreneur and evangelist too.