Sharing government services — next steps
Thanks to Hugh Wells for helping me think this through.
A step along the way
In my previous blog post about some of the things GDS could have done better since its inception in 2011 I wrote at length about how “government as a platform” could have been implemented differently. My vision is still for government to largely have a single shared digital environment made up of common components. We’re a long way from that happening so the question is what is a sensible first step to move us on the way?
Open source hasn’t been the panacea we’d hoped for
One of the things GDS did insist on as part of the Service Standard was that new software code produced by government should be open source. This means that other organisations can take the code for free and “spin up” their own instances. In reality I don’t know of a single instance where this has happened with a whole service — it does happen a lot with excellent components such as the GOV.UK Design System.
In central government this makes sense as different organisations have responsibility for providing very different services. However, this isn’t the case in local government where 100s of different local authorities provide often near identical services — often purchasing a “common off the shelf” system from a small pool of software providers.
Multi-tenant services
If providing reusable software isn’t working, is there a better option? I believe so and would like to see a serious experiment of simultaneous use of the same live software products by multiple local authorities — sometimes called “multi-tenancy”.
There are a number of hurdles to testing multi-tenancy in a real-world environment but I don’t believe that any of them are insurmountable. At the very least the following points would have to be addressed.
Designing and implementing services for multi-tenancy usage
This, more than potentially anything else, will be a leap of faith for the first few organisations that undertake it. It’ll require spending more time, and therefore money, to produce something that will be inherently more complex and require not just expanded technical support but also additional governance. To begin with we need a small number of forward thinking local authorities to lead the way — to think beyond satisfying the needs of their local resident and staff users to how they can support a wider ecosystem of local government digital services.
I believe a key part of this will not only be publishing all the code for such services as open source but actively encouraging client organisations (other local authorities) using the service to contribute their own improvements by submitting software patches that they develop for it — building on the concept that the work needed to do that will support a number of other organisations.
Finding and joining such services
In order for local authorities to find multi-tenant services for them to use I believe we need to create a “services service” (needs a better name) to support a marketplace for such things. Part of this would be supporting onboarding local authorities to the ecosystem, part would be configuring branding and how use of data is supported (see below). However, the most important parts of it would be in supporting the business relationship between service providers and client organisations (contracts, finances, etc — again, see below).
Alongside encouraging organisations to produce the first multi-tenancy services to put in the marketplace, I believe that providing the MVP for the “services service” is the most important thing we can be working on right now in terms of immediate next steps to make this ecosystem a reality.
Branding
It’s important that users should feel that the digital service they are using is part of the organisation they are working with. When they step off their local authority website to the multi-tenant service they shouldn’t notice any difference. Not my area of expertise, but since most local authorities are now converging on producing services based on the GDS Design System it shouldn’t be that hard to support the use of a minimal amount of branding CSS (colour scheme, logo) via the “services service” to achieve this.
GDPR and other data issues
How a multi-tenancy service would handle data is one of the more interesting, complex and potentially difficult parts of this proposal. People would be quite right to discuss the GDPR implications — something I don’t feel qualified to elaborate on specifically.
AT a high level my thoughts are that there are essentially two possible approaches. One is to offer to store data for each organisation in a partitioned area within the service itself. The service owning organisation would act as a data processor and would contractually promise not to touch the data for any other reason. The other would be to ask any client organisation that wants to use the service to provide a set of standardised secure public APIs to enable data to be sent and received that way. In the latter the service owning organisation is still a data processor but the data remains remote — safely under the control of the client organisation.
As with the whole idea of multi-tenant systems in general, I think a number of different experiments can be tried for different ways to work with data belonging to multiple organisations.
Cyber-security
Having open source code is a great start to assessing the digital security of any product. Potentially having multiple organisations looking at the code and associated tests and ideally submitting patches would definitely help. Modern live-service security testing would also be necessary. Basically, the more groups that want to get involved in discussing the security of a specific service the better.
Accountability, responsibility and risk
This is probably the most important question to address for this method of providing digital services. The first, and extremely reasonable, question many people are going to ask is “what happens when something goes wrong?” This is why I believe that providing and consuming these services will be very different from signing up to a simple cloud software-as-a-service platform. There will need to be contracts signed at senior levels in both organisations. Those contracts will need to be explicit about downtime, service capacity reduction, loss of data, etc. They won’t be significantly different from the kind of contracts that a local authority may have with a private sector software provider. This is an area that will require considerable careful thought but I don’t feel any of the related issues are impossible to overcome.
Financial model
I would suggest that if the cost of scaled usage of the system remains relatively low then usage of the system by client organisations could remain free. However, if costs do start to scale up then there a wide variety of ways to approach this, including fixed term costs (pay for period of use), per user costs (pay for number of citizens or staff using the system) or per usage costs (pay for numbers of transactions).
One thing I would suggest would be a discount to client organisations who are involved in improving the service either through cyber-security participation or submitting code patches. This is another way to encourage more active involvement than the standard vendor / client model.
Localism (who gets to say how the service works)
One of the arguments I hear most often against the idea of multi-tenancy is that every organisation has different ways of working and that multiple local authorities won’t be able to come together to use the same live services. My main counter to that is that this proposal is an optional alternative to the existing situation where local authorities are already forced to, by and large, work in very similar ways as they are constrained by the limitations of the software they use to manage their services to residents — which is turn come from a very small pool of providers.
If anything, services that form part of this marketplace would be better as, if a local authority wishes to add or change a piece of functionality, they would be able to use in-house developers or hire someone to create the update they want and then submit it for inclusion into the system. This is very different to working with the existing pool of commercial providers where suggestions are, at best, added to a long roadmap — if they are acknowledged at all.
So, what next?
I’m open to the possibility that the above issues may make it too hard to create and maintain multi-tenant software services, but I think it’s important that we try. The duplication of spending on very common tasks such as rent collection, paying council tax or paying parking fines leads to a huge unnecessary drain on the public purse.
I believe the next steps are to build a MVP of the “services service” and encourage multiple local authorities both to try using some of the services in that marketplace but also to commit to submitting their own. The latter could easily become a declared commitment as part of signing up to the Local Digital Declaration for some local authorities.
Perhaps the biggest step is encouraging “how can we” thinking in local authority digital teams in terms of designing and building services that are ready to be used by other local authorities on initial release. This will need not only serious technical and data considerations to make it even possible, but also considerable management buy-in, in terms of how to offer such services in a way that can be contractually acceptable.
The one thing I haven’t touched on here is whether commercial third parties should be allowed to put their products in this market. I’m inclined to think the answer is yes — but in addition to all of the conditions listed above (including accepting patch submissions) the associated contracts would have to include this proposed text from LOTI confirming API access to prevent the data lock-in that has plagued so many existing local government legacy systems.
Like the early days of GDS it feels like a combination of technological advances, restricted finances, desire to break with the current supplier cartels and an increasing spirit of openness is moving us in a direction that is primed for just this kind of experiment.
I’m very keen to see where it could take us.
