Government as a Platform: the foundation for Digital Government and Gov 2.0

article-body

THE PIA REVIEW: PIA ANDREWS This is a Public Sector Pia Review — a series on better public sectors.

This article explains the idea of “Government as a Platform”, commonly known as GaaP, including the benefits, challenges and how you could apply it in your everyday work, regardless of whether you work in policy, regulation, service delivery, or anything else. In short, GaaP provides a framework and methodology for designing, delivering, and dramatically improving the impact, scale, and effectiveness of public sector efforts and policy outcomes.

The term “Government as a Platform” was originally coined by Tim O’Reilly, influenced by the broader “as a platform” paradigm shift where business models were emerging, influenced by the internet and Web, that shifted towards service-oriented architecture and distributed ecosystems of service providers: ‘platforms’ upon which anyone could leverage common components and value-add through building apps or tools. Tim proposed that governments should open up the doors so that the private sector could build on the back of government digital infrastructure (like open data) to better serve a rapidly changing market. I take this one step further to propose that “Government as a Platform” is an important principle not just for technical architecture, but for policy and program management, as it implies that no problem can be solved by any one organisation alone, but by collectively making the things we each do discoverable and mashable by many, and by assuming that complex issues require a collective of systemically motivated contributors. In this way, we can create the foundations for a robust, diverse, and resilient ecosystem of services and converging efforts towards increasingly better public outcomes. Government can, and should, reliably provide certain fundamental parts of a “social and economic platform” for society, but exactly the remit of government is subject to different cultural and political norms in different countries. I’ll discuss what I think those foundations are in the Australian context further below.

Government as a Platform provides the necessary foundation for four key benefits:

• For government programs and policy to be responsive, resilient, and relevant throughout a time of increasing societal and economic change. In splitting the front end from a consumable series of back end services, agencies gain the ability to more rapidly iterate the customer experience of the service, taking into account changing user needs and new user platforms (mobile is just the start — personal AI helpers, augmented reality and embedded computing are just around the corner). When the back end and front end of a service are part of the one monolithic codebase, it is simply too expensive, time-consuming, and complicated to make any changes to the service, let alone support continuous improvements or respond to changing user needs.
• To digitally enable everything we do in government for better service delivery, modern and scalable approaches to regulation and compliance, better risk and security management, more efficient and effective outcomes and the possibilities of bringing persistent policy, evidence, and implementation brought together to ensure we are collectively heading in the right direction.
• To enable an ecosystem of services, products, and other value-add on the back of public investment (like data & research), digital public infrastructure (like regulation as code, service catalogues, eligibility engines), and the economies of scale for which governments are uniquely placed to take advantage of (like space infrastructure, national security and spatial tools, census data, etc).
• Automation and dynamic service delivery — the final and least shiny benefit, ‘though the most interesting from a service-improvement perspective, is automation and integration. If your data, content, transaction systems, and rules are programmatically available, you create the opportunity for holistic service delivery across portfolios and jurisdictional boundaries, such as the different steps of a life event to be integrated or automated where personal consent is granted. The user-consent part is really important, just to be clear! So rather than having 17 beautiful but distinct services that a person has to complete individually, a user could be asked at any one of those entry points whether they’d like the other 16 steps to be automatically completed on their behalf. Sometimes, the best way government can serve citizens is to get out of the way.

Outsourcing service delivery?

Government as a Platform is certainly not about public sectors just providing APIs and letting the ‘free market’ solve all problems. That would be a disaster, as it has been everywhere that has attempted to privatise all public infrastructure, but especially so in a country like Australia, where we value public infrastructure and services as a basis of economic and social stability and a foundation upon which people can thrive. It also isn’t feasible or sustainable. Public sectors should always provide key public services for which they are uniquely motivated, authorised, or that are in the broader public or economic interest — even when there are private or non-profit sectors providing related or competing services — for four important reasons:

1. The public sector necessarily needs to provide inclusive services to all citizens, as opposed to other sectors that are naturally motivated to serve sustainably profitable customer segments.
2. By providing a baseline quality of service to the public, the public sector can create an upwards pressure on the market to provide a minimum threshold quality of services to the public, the ‘sedan’ of service delivery where the Ferraris and unicycles can be provided by the private sector. Public sectors can provide open-source reference implementations and developer kits to help ensure a consistency of quality or experience, as we do with business APIs provided by the ATO.
3. The public sector is accountable to the public, parliament, and government of the day, and key public services should have oversight to help ensure they don’t create harm, inequity, security risks, or illegal outcomes, especially when you consider key areas of government responsibility like high-integrity identity credentials (birth and marriage credentials, passports, etc), social services, taxation, customs, defence, standards, and many many more.
4. The public sector is not (or shouldn’t be) driven by a profit imperative, which means there are less pressures to make money from citizens, and more pressures to serve the public good.

This is certainly not to say that government should do everything. We need to be careful to not overplay or underplay the role of public sectors in society, and the general polarised narrative of all or nothing obviously doesn’t help navigate this issue effectively. We need to be clearer and confident in what roles the government should clearly play and stop seeing absolutely everything as contestable if we are to ensure that balance is appropriately maintained.

So, what does Government as a Platform look like and what role do public sectors play?

A brief explanation and history of Government as a Platform

As mentioned, the term “Gov as a Platform” was coined by Tim O’Reilly  in 2009. He spoke about the potential to transform government into a platform, similar (for those unfamiliar with the “as a platform” idea) to Google Maps, or the Apple/Google app stores. Basically, government could provide the data, content, transaction services, and even business rules (regulation, common patterns such as means testing, building codes, etc) in a consumable, componentised, and modular fashion to support a diverse ecosystem of service delivery, analysis, and products by myriad agents, including private and public sector, but also citizens themselves.

Seems obvious right? The tech sector has been taking this approach for over a decade.

What I have found is there a lot of interest in ‘digital government’ where it is usually just digitising an existing process, product, service, or channel. The model of consumable, modular architecture as a strategic approach to achieve greater flexibility and agility within an organisation was, while enabling a broader ecosystem to build on top, simply not well understood by many, though althat is starting to change. Certainly there are pockets that understand this, especially at the practitioner level, but agencies are naturally motivated to simply delivery what they need in isolation from a whole of government view. It was wonderful to see New Zealand picking up a whole of government GaaP approach in 2017 in this vein, but many governments are still focused on simple digitisation rather than system transformation.

Gov as an API

One of the greatest impacts of the DTA and the UK Government Digital Service has been to spur a race to the top around user-centred design and agile across governments. However, these methods, while necessary, are not sufficient for digital transformation, because you too easily see services created that are rapidly developed and better for citizens but still based on bespoke siloed stacks of technology and content that aren’t reconsumable, and then aren’t extendable or adaptable to ongoing changes in user needs. Why does this matter? Because there are loads of components needed for multiple services, but siloed service technology stacks lead to duplication, a lack of agility in iterating and improving the user experience on an ongoing basis, a lack of programmatic access to the components that would enable system to system automation, and a complete lack of the consumable and mashable service components, the “platform” or foundation, upon which an ecosystem could be built.

The key to success in implementation is to take a Unix/Linux mindset of having many simple things that do one thing really well and can be integrated, rather than trying to build highly complex functions that try to be everything to everyone (and end up being either so generic or so complex as to be nothing to anyone). It is about making it simple to reuse those things that are worth being reusable so they can serve many purposes. It’s also useful to note not all components will be APIs — some might be SQL views, or an events bus, or verifiable claim, so assume gov as an API is shorthand for gov as a series of easy to use programmatic interfaces.

When I was at the interim DTO in 2016, we realised that no single agency would fundamentally ever be naturally motivated, funded, or mandated to deliver services on behalf of someone else. So, rather than assuming a model wherein an agency is expected to operate against their own interests and vertical accountabilities, we started considering new models. New systems wherein agencies could achieve what they needed (and were mandated and funded) to do, but where the broader ecosystem could provide multi-channel services delivery for which where there is no wrong door for citizens to do what they need. One channel might be the magical ‘life events’ lens, another might be third parties, or state and territory governments, or personal AI helpers, or citizen mashups. There are many agents, organisations, and sectors that have persistent relationships with their customers or clients, allowing them to exponentially spread and maintain user-centred design in ways that individual agencies by themselves can not afford to do, now or into the future.

This vision of Gov as a Platform was just a reflection of the Amazon, Google Maps, the Apple ‘apps store, and other platform models so prevalent in the private sector as described above. But many governments have, to date, largely interpreted ‘Gov as a Platform’ as simply common or shared platforms or shared services. While common or shared platforms can provide savings and efficiencies, it has not enabled the system transformation needed to get true digital transformation across government or third-party value-add on the top of reusable government service components.

So what does this mean practically? There are, certainly, pockets of people doing or experimenting in this space. Here are some of my thoughts to date, based on work I’ve done in Australia (at the interim DTO), in New Zealand (with the Department of Internal Affairs), and in New South Wales.

Firstly, you can largely identify four categories of things involved in any government service:

• Content — obvious, but taking into account the domain-specific content of agencies also as the kind of custodian or contextual content usually managed by points of aggregation or service delivery;
• Data — any type of list, source of intelligence or statistics, search queries such as ABN lookups, services catalogue, persistent evidence base, or service analytics’
• Transaction services — anything a person or business interacts with, such as registration, payments, claims, reporting, etc. Obviously, they require strict privacy and security frameworks; and
• Business rules — the regulation, legislation, code, policy logic, eligibility engines, or reusable patterns or algorithms (such as means-testing) that are usually hard-coded into projects as required. Imagine an authoritative public API with the business logic of government available for consumption by everyone. For more on this concept, see this Rules as Code presentation.

These categories of components can all be made programmatically available for the delivery of individual initiatives and for broader reuse either publicly (for data, content, and business rules) or through strict controls (for transaction services). But you also need some core capabilities that are consumable for any form of digital service, below are a few to consider.

• Identity and authentication, arguably also taking into account user-consent-based systems that may be provided from outside of government.
• Service analytics across digital and non-digital channels to baseline the user experience and journey with government and identify what works through evidence. This could also fuel a basic personalisation service.
• A consistent government web platform/experience to manage and draw together relevant government information for service delivery.
• A services register in the form of a consumable register of government services (human services) to draw from across the board.
• A public eligibility and calculation engine, to make the rules of eligibility and calculation (much of which are in legislation) available as an API for anyone to consume, including government agencies themselves.
• Legislation/regulation as code, because if all prescriptive legislation and regulation were machine consumable, it would create enormous efficiencies, improved regulatory and compliance outcomes, improved policy outcomes, and greater explainability and traceability of decision-making while still allowing for appropriate judgements in principles-based legislation.
• Payment, notification and verification services, which are common but duplicated across government. The UK has done great work in identifying and building reusable service components/platforms like these in their service toolkit.
• The structures of government, because if we had a digital representation of government that reflected the structure, lines of responsibilities and legislative authority, portfolios, departments, programs, and even budgets, we’d have the basis for more automated, efficient, effective, and agile government, especially when you consider the regularity of machinery of government changes. Imagine being able to say “this area of responsibility now reports to this minister and secretary” and all our systems automatically are reflecting the change, rather than the extremely manual and high effort required to do it today. Please see the excellent article by Allan Barger on creating a digital twin of government for more on this concept.
• A series of verifiable claims for common requests in service delivery, which would then reduce the need for data-sharing and dramatically reduce the cost, processing, time, and indignity around many services today. For instance, rather than having to take a payslip in to prove your income for a social service or tax credit, imagine if the service delivery agency could say “do you give us permission to verify with the ATO that you meet the means test?” Imagine if we took a conditional approach to matters, where you don’t need to provide documentation to prove your age (birth certificate, licence, passport), all of which give too much information, but rather can provide a verifiable claim that “yes, I am over the required age”. See the verifiable claims work by W3C for more info on this concept, but it could be a huge transformation for how gov and privacy operates.

Government 2.0

As an aside, Tim also defined Government 2.0 in the best and most prevailing way I have seen, and it encourages me to continue to use the term:

“Government 2.0 is not a new kind of government; it is government stripped down to its core, rediscovered and reimagined as if for the first time. And in that reimagining, this is the idea that becomes clear: government is, at bottom, a mechanism for collective action. We band together, make laws, pay taxes,and build the institutions of government to manage problems that are too large for us individually and whose solution is in our common interest. Government 2.0, then, is the use of technology—especially the collaborative technologies at the heart of Web 2.0—to better solve collective problems at a city, state, national, and international level.” — Tim O’Reilly, Government as a Platform (2010)

The real opportunity of Government as a Platform is the ability, as Tim puts it, to reimagine government and work towards fundamentally better public outcomes in accordance with the values and culture of the society you serve. Government as a Platform is a crucial enabler for Gov 2.0, and indeed for any fundamental transformation of our public sectors to be fit for purpose in the 21st century, as it represents not just a technology or design principle, but rather a paradigm shift to governments operating more like a series of high-value nodes in a network that feeds from and into a complex and interdependent global social and economic structure. Governments have some special and unique responsibilities, but the more we can operate like a foundation upon which others can build value, the more we contribute to greater public outcomes and the greater an impact we can have for less effort than it would take to do it on our own.

If you are interested in public sector reform, I recommend you tune in to or attend the upcoming Gov 2.0 Taskforce: Ten Years On event. It will be a chance to reflect on the progress we have made, new challenges or opportunities that have surfaced over that time, and what we can do about it as optimistic people who care about great public sectors to service great public outcomes.

Final word — Government as a Boat

Although most of what I’ve covered above is most obviously relevant to service design and delivery, hopefully people in other areas of government will consider the useful implications for policy, programs, regulation, and more. If you see the world as potential collaborators or contributors to what you are trying to achieve, and actively seek our naturally motivated parts of the system you are interacting with, then you start to naturally design and deliver ways of operating that will have greater impact, and that enable and leverage greater resources than you will ever have at your disposal. Taking a modular, agile, and mashable approach to whatever you are doing, and assuming that your role is to be both a doer of great things and an enabler of many others doing great things, is quite a profound change in worldview.

I believe that when operating at their best, public sectors are like a giant ship. There are lots of moving parts, various specialist teams operating in unison to keep all the passengers above water regardless of where they sit. When those specialist teams don’t communicate, don’t head in the same direction, or try to hand the oars to the passengers, it gets increasingly hard to ensure everyone has what they need and are kept safe on their journey. If you make those teams compete, then you end up with holes emerging and water gushing in. To torture the metaphor, it is particularly unhelpful when people steal the life-rafts and drift alongside yelling that no one really needs the ship anyway, while still relying on the ship’s kitchen, medical supplies, slipstream, and protection against sharks and storms.

Government as a Platform is also like that giant ship: a platform for people to stand upon, to be safe and to thrive. Our job is to make sure the ship doesn’t sink, to maintain a steady course, and to maintain the ship as required. Perhaps we need now to upgrade to a hovercraft or spaceship to better serve the changing needs of the communities we serve and reflect the changing times. But we can’t change strategy or course if we don’t acknowledge that public sectors are and have always been a platform for successful societies, we will always be government as a platform.

Many thanks to the various folk who provided great peer review on this post including Chris Gough and some great public servants who’d prefer to remain unnamed.

Useful references

• Tim O’Reilly’s paper on Government as a Platform
• Government as a Platform: a Value Propositions Discussion Paper by Brock Jera and Pia Andrews
• A Government as a Platform guide by Richard Pope which provides great guidance backed by substantial research.
• Government as an API: How to change the system (speech) by Pia Andrews
• Article by Derek Alton from Canada on Gov as a Platform
• Article on why digitally created and consumable rules (like legislation) are required for better government, better services and better compliance, by Tim De Sousa and Pia Andrews
• Allan Barger’s article on the need for a digital twin of government to optimise the day to day operations and continual changes happening to our public sectors
• A list of common registers, components and open APIs used by governments around the world