The principle of ‘small parts loosely joined’ is an established approach to designing technology. It’s nicely summed up by the so-called Philosophy of Unix — a set of norms and approaches that describe how software should be designed. Among other things, it includes these three principles:

Write programs that do one thing and do it well.

Write programs to work together.

…. Design and build software … to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

Modern digital services also tend to be designed in this way. They are built around micro services so that different parts of an overall service - for example, signing in using a username and password - is a separate component and from other parts of the service - such as sending a notification to a user or accepting an payment. This means that different components can be replaced more easily and, when a change needs to be made to how a user signs in, it can be made without waiting for a change to some other part of the service.

‘Platform-as-a-Service’ offerings, from the likes of Amazon Web Services and Microsoft Azure (that software developers rely on to develop their services quickly), also follow this approach. They are generally focused on a clear task like ‘send an email’, or ‘run a database’. Simple platforms are easier for software developers to use because it is clear exactly what they do (it’s worth noting how many of Amazon’s platforms start with the word ‘simple’). Plus, because they are not tightly coupled to one particular use case, they can support multiple outcomes — a service for watching videos can be built from some of the same components as one for ordering a taxi.

Platforms in government

Generally speaking, this has not been how software for public institutions have been built. Governments have tended to build technology in silos that reflect the organisational structure of different departments and agencies.

However, looking around the world, we can see a ‘small parts loosely joined’ approach emerging in the digitisation of government too. Things like payment systems, secure messaging, registers of land and companies, identity verification, tax rules - are being built once and used multiple times. The work of government is slowly being reorganised around shared APIs and components, open-standards and canonical datasets. Broadly, this is the realisation of the world sketched out by Tim O’Reilly in his 2011 article Government as a Platform, where he posed the question: what if government was organised more like an operating system?

The implication of government-as-a-platform is that more of the functions of the state should operate in a more networked way, with more ‘horizontal’ shared components and less silos. The hope is that this will allow public servants, businesses, and others to deliver radically better services to the public, and to do so more safely, efficiently, and in a more accountable way, than applying digital technology to 20th century institutional silos.

Do digital public goods fit the platform model?

One key question for the commissioners, developers and consumers of digital public goods will be: to what extent do individual examples of digital public goods fit this emerging model of digital-age government? Are they ‘horizontal’ platforms that support multiple outcomes? Do they support interoperability and standards? Or, conversely, do they reinforce silos?

There are some positive signs in this respect. Projects like the open-source identity platform MOSIP and the digital payment system Mojaloop, which are regularly referenced as examples of digital public goods are unashamed ‘horizontals’. They are designed not to be the solution in themselves but to be enablers. Tomicah Tillemann from New America’s Digital Impact and Governance Initiative has also written about digital public goods forming a civic stack made of components that work together. While the five-year strategy for the Digital Public Goods Alliance, written by Liv Marte Nordhaug and Lucy Harris, talks of the need for “horizontals, solving problems impacting [the state]”.

However, while these are positive signs that digital public goods may map well to the government-as-a-platform approach, there is also a risk that the lack of a robust scope and set of characteristics for digital public goods means that they could become all things to all people. The registry maintained by the Digital Public Goods Alliance, for example, contains everything from chatbots to the websites of specific organisations and visualisations of individual datasets. While it is likely a good thing that these have been assigned an open-source licence, it is hard to see how some of them could be easily reused or how they could be combined to create something greater than the sum of their parts.

A sceptical reading of the digital public goods approach would be that it represents a repackaging of e-government, civic tech or GovTech. It could also be compared to the early open data movement, which prioritised the publication of data under an open licence as the first and most important step, but often found it hard to ensure sustainability and interoperability of what was published. There’s a risk that ‘performative openness’ undermines outcomes that are sought. The meaning and intent could drift.

If digital public goods are going to support the emerging platform model of the digital state, and if they are going to be genuinely optimised for reuse, funders will need to get more opinionated about what the label ‘Digital Public Goods’ gets attached to. They should prioritise things that are genuine pieces of infrastructure and focus ruthlessly on interoperability.

So, what makes for good digital infrastructure? Here’s a non-exhaustive list of things that those backing digital public goods as infrastructure should think about when identifying good platforms.

• Simplicity - does it do one thing and do it well?
• Clear scope - it should be clear where something fits in the overall ‘civic stack’ and if it is designed for use by a single public institution, or by wider society.
• Ongoing development - does it have a team and funding in place to continuously improve it?
• Ease of use - can it be used ‘as is’ or does it require customisation? Doers it have well designed documentation and open-source code libraries (in addition to the core piece of software)?
• Solves a common need - is it meeting a genuine need for multiple use cases, and is there evidence for it?
• Governance model - does it have a decision-making process that represents the interests of all users not just a single organisation?

The digital public goods approach could enable governments to fast-track to something along the lines of government-as-a-platform, but that may mean funders being more opinionated about what constitutes a digital public good, at least when it comes to infrastructure. This is, I think, another example of a question that was once the domain of technologists moving into the domain of funders and policy-makers. At a tech company, it would likely be someone with a job title like ‘technical architect’ making the decisions about what components should exist and how they should join together. Whose job is it at a funding organisation to ensure that digital public goods encourage interoperability, rather than silos? Who should decide what ‘small parts loosely joined’ look like in this world? In deciding what to support, are funders going to need to act more like technical architects? Will they commission research to understand the most common needs for digital infrastructure? Can they help ensure the wider sector has a clear understanding of what makes a good platform?