As Ash Stephens explained, Government as a Platform will provide a suite of common tools and components (eg GOV.UK Pay and GOV.UK Notify), that will make it easier for the digital teams in government to build services and accelerate transformation.
During our alphas we’ve been thinking more about how our products will work across government, and the needs of the teams building and running services. While doing that we’ve realised something important.
It's highly likely that services built using these products won't just use one product in isolation, they'll use several. So instead of thinking of each product as a single ‘platform’ (eg GOV.UK Pay and GOV.UK Notify), we need to think about them in the context of service patterns, data and reusable code. Together they'll form a single platform on which government can build brilliant transactional services.
Think of Government as a Platform as a toolbox that service managers can rummage in, to find the best tool for their job.
We also need to think differently about the needs of the service managers and technical architects (and their teams) who build and run services that might use Government as a Platform. We shouldn't limit ourselves to thinking about their needs in relation to just one product, instead we should be considering their needs in relation to the whole range of products and how they work together.
Thinking about needs
We think service teams need:
- the components of their service to be modular, so they can build and operate services that meet their user's needs
- components that are easy to integrate in to their service, in order to minimise costs and speed up development
- the components of their service to be actively supported and maintained, so that they can be confident that their service will continue to run
- support and maintenance for the components to be consistent, to minimise cost and complexity
- data and transparency about the performance of the components so they can have confidence in their value
This will have implications for how government builds and runs Government as a Platform components, not just those built in GDS, but those built in departments too. So we need to identify the common principles that will shape how components are built and run. These components will then make up a consistent and coherent platform, which service managers will trust to support the transactional services they build.
Over the next few weeks we'll share our thoughts on what these principles will look like.
Follow Seb on Twitter, and don't forget to sign up for email alerts.
1 comment
Comment by Paul Smith posted on
This is great, each 'product' should do essentially one thing ('pay', 'notify', 'verify', etc) well but be developed in a way that allows it to hand off to the next or back to the service where that is more appropriate. It's not trivial to implement (and I'm interested in hearing more) but as you say, it should allow composition of those products to form a specific service. That is what I imagine when I hear 'Government as a Platform'.