Having both worked for the UK Government Digital Service in its early days of formulating the ‘Government as a Platform’ (GaaP) approach, Richard Pope and Antonio Weiss outline some of the initial considerations for developing and funding GaaP and invite views about where next to focus their efforts.
“Government as a platform” (GaaP) has come to mean many things to many people since the term was introduced by techology guru Tim O’Reilly in 2001. Broadly, the term refers to a whole ecosystem of shared APIs and components, open-standards and canonical datasets, as well as the services built on top of them and governance processes that keep the wider system safe and accountable. However, it is best conceived as a means to securing outcomes that include – but are not necessarily limited to – better public services, fewer operational silos, a toolkit for governments, open platforms for anyone to build on, a digital public infrastructure and new institutions for the digital age, and the joining up of policy and services (Pope, 2020). For many countries across the world, GaaP – exemplified by Estonia’s X-road platform, Britain’s GOV.UK Notify service or India’s Aadhaar infrastructure – has become the defining approach for how to become truly digital states.
The GaaP approach, is necessary to join up policies across boundaries of departments, agencies and also levels of government. In the UK, for example, local authorities have adopted GaaP components, such as GOV.UK Notify messaging service. However, the approach presents big challenges for government policy makers: who should pay for platform capabilities; how should they be paid for; who is responsible and accountable for their delivery, upkeep and oversight; and what risks are involved in a GaaP approach?
Funding options available to policy makers
To date, the approach of GaaP has spawned a variety of products, services, and components that broadly fit into three categories (OECD, 2020):
- Ecosystems such as centralised spending controls, shared APIs, and commodity services;
- Marketplaces which enable public, private and third sector delivery of services, giving citizens the freedom to choose which approach works best for them; and
- Ways of changing the relationship between citizens and state, such as crowdsourcing.
Whilst many look to the UK as a GaaP pioneer (and the UK comes top on the GaaP dimension in the OECD ranking), countries as varied as Argentina, Canada, Denmark, Estonia, India and South Korea and others have proactively developed API-led GaaP strategies.
Each GaaP element needs to be paid for yet no country has taken a uniform approach to funding for all elements, given the diversity of GaaP components. Below we outline the key issues for policy makers:
Ownership and maintenance
Given that one of the primary aims of GaaP is to reduce operational and organisational silos, there is often a strong desire for a central body to take the lead here. However, central departments often have short lifespans and may be smaller in scale and influence than more established government departments. If a platform is developed by a single government department, a pathway should be set out for how it could become generalised and used across government so the internal priorities of that department do not skew the development of the platform. A number of the major “FANG” (Facebook (F), Amazon (AMZN), Netflix (NFLX), and Alphabet (GOOG)) technology companies use this approach. In the case where a local or devolved governments make use of a shared platform, new organisational structures may need to be considered.
The nature of shared platforms is that they cost less per user the more they are used, given the high fixed initial costs. They also create value that cannot be understood in advance. If a platform is developed by an established department, the department will need mechanisms to spend money from their own budget on outcomes beyond the departmental policy area. Alternatively, as in the UK, funding could be granted from a central investment pot. How this central investment pot is financed is important: this can either come from top-slicing from government departments or from existing government reserves.
Scaling up is important to the success of the platform approach. The first five users of a well engineered hosting platform do not deliver a good return on investment. However, once fixed costs are covered, costs per user significantly drop. Pricing on the basis of cost-recovery will risk impeding take-up, so it is self-defeating. Rapid scaling also means that it is not possible for the organisation operating the platform to maintain an individual relationship with each user of a platform. GOV.UK Notify – a messaging service that has now passed over one billion messages – provides a good solution; it adopted a freemium model to minimise barriers to uptake and spent significant efforts towards making the service onboarding process as seamless and self-service as possible, now at around seven minutes.
Paying for “open”
A key element of GaaP is the idea that digital public services should create and maintain open APIs that others can build on. A benefits agency might maintain an open API for benefit entitlement that could be used by banking and budgeting apps. However, this means that the benefits do not usually accrue to the department or body which creates and runs the API. A wider governmental view needs to be taken and funding granted to a department to create an API because it benefits others, rather than funding being withheld because it does not directly benefit the host department.
Traditional government project funding adopts a “waterfall” programme management stage-gate approach – funding is released in tranches and contingent on “milestones” being hit. This creates challenges. It assumes linear delivery, which is rarely the case when new digital services are involved and can create a bureaucracy of continuous business case development to secure funding.
- Digital teams need to work jointly with finance teams to develop a long-term financing blueprint. Key questions to address include: to whom do the benefits accrue?; how long before “scale” is reached?; is there a buffer in the funding arrangements for the platforms pivot to a new user need, should one emerge?
- When funding platforms, recognise the uncertainty of what is being created. How much certainty can you really have about the next three to five years? What are the core benefits that need to be delivered versus additional benefits that may – or may not – emerge as the platform matures?
- Create the flexibility to move the platform from one body to another. Just because a platform was created by a particular state body does not mean it needs to remain there in perpetuity. Consider whether moving it to a different environment might help encourage its more generalised use.
We are grateful to the thoughts of many who’ve already contributed to this research and we would value your views on where to take investigations next. Please do reach out to email@example.com or firstname.lastname@example.org with thoughts.