In our previous blog post we explained why we’re thinking about Government as a Platform as a consistent, interoperable product range.
An important part of this is making sure that common tools, services and platforms are trusted by the service managers whose services will use them. Service managers need to know that: the tools, services and platforms are based on user needs; they’re of a high quality and they’ll be supported for as long as they’re needed.
So with that in mind we’ve drafted some principles (similar to the GDS design principles), for teams across government to follow when building and running products and components for the Government as a Platform toolbox.
Principles for Government as a Platform products
Meet a common need
Products should meet a simple and common need, shared by a wide range of services across government.
Be independent
Products should be run for the benefit of government as a whole, not just a specific service or department.
Commit to maintaining the product
Products should be supported at the highest level of the organisation to make sure there’s sufficient people and money to keep it running as long as it’s needed.
Make it easy for the user
Products should support services to provide a high quality, straightforward user experience.
Be easy to integrate
Products should be quicker, cheaper and easier for service teams to use, rather than implementing their own solution to meet the same user need.
Be ready to grow
Product teams should have processes in place to respond quickly to service teams wishing to use the product, and to support any subsequent increase in usage.
Be easy to adopt
Service teams should be able to get started without direct support from product teams, by following clear processes, documentation and code.
Support service separation
Each service's data should be kept separate. Activity from one service mustn’t affect another.
Avoid being tied down to one supplier
If products use suppliers, service teams should be able to choose from multiple suppliers and change quickly from one to another.
Meet technical and design standards
Products should be designed to meet the Digital Service Standard and the Technology Code of Practice. This will make integration with services easier.
Be open about performance
Teams should publish data about the product including future plans, performance, coverage, targets and incidents so that service teams can make informed decisions.
Be open about cost
Be clear about what it will cost a service team to use the product.
So what do you think? We’re keen to hear from teams across government so that we can build a set of principles that work for, and are trusted, by everyone. Email us your thoughts or leave a comment below.
Follow David on Twitter, and don't forget to sign up for email alerts.
2 comments
Comment by Paul Murray posted on
Running the Common Web Platform here in New Zealand, I am keen to understand more about your thoughts on open cost, in particular when there are vendors involved, as we often have here in NZ.
Comment by @postenterprise posted on
I saw an earlier set of principles months ago which made clear that platforms are not products, and made clear also the desirable size and complexity of a platform.
Too many people love the latest buzzword and relabel stuff that isn't a platform as a platform. Like HR shared services ..
It would be valuable to help readers make this distinction.
Id would make really loud: Platforms are not products! .... don't encourage bad sharing of user interface and user experience - that's crafted per user group, by shaping products built on platforms. Platforms help build products, they don't satisfy user needs themselves.