Many in Government, and some commentators, are promoting the concept of Government as a Platform (GaaP).
A video issued by GDS gives a high level view of GaaP and states: “We think there is a simpler, easier way [than the independent service silos developed in the past that led to duplication]. It’s an idea called Government as a Platform. It breaks things down into smaller parts like building blocks. Each block does one job. It’s easy to connect blocks together and easy to scale them up when demand increases. If some part of the service breaks we can fix it or upgrade it easily”.
It concludes: “This is what we mean by Government as a Platform – Better, smarter public services.”
Essentially, it appears that a platform can support any common function that is required by a number (perhaps all) of government organisations AND successfully consolidate demand.
This is an impressive aim that, in some senses, reiterates the Service Oriented Architecture (SOA) concept at a whole-of-government level. SOA is a mature model and generally well understood.
However, it has never been implemented at this scale for an organisation as diverse as the UK government. I believe it is worth looking at some of the implications of this in a little more detail.
Is it really that simple?
One possible example of GaaP of which much has been made is the appointment platform, which aims to offer citizens a single way to book appointments with any government department.
However, are all appointments the same?
Some attributes will be common but others will vary depending upon the context. Thus, a common appointments platform could become quite complex.
There will always be ‘edge’ cases and platforms should not be over- engineered. However, a lowest common denominator approach will not encourage their successful reuse. They need to be designed to a level that does consolidate demand whilst driving adoption of the GaaP approach.
A potential generic model for GaaP is the provision of a common platform software component made available for access by other components relating to specific scenarios. The common component will necessarily be more complex than a simple one-off solution.
Guidance must be developed to ensure platforms are specified and developed in ways that make future re-use easy. Publishing APIs, establishing common standards and opening up platform information will help other departments to develop the functionality for specific scenarios whilst reducing their development effort by exploiting the common platform component.
What about data?Data is specifically mentioned in the GDS video which states “Platforms can be opened up too, allowing 3rd party services to use government data”.
The benefits of opening up data are considerable, and it offers huge potential for innovation.
However, it’s of utmost importance to ensure privacy and data security are maintained according to clearly defined rules. Failure to do this could engender further public distrust of government IT schemes, and seriously impede benefits realisation from GaaP.
What is needed to make GaaP a success?
The platform concept has been likened to the Apple model for its iPhone, where a common operating system and back-end infrastructure empowers a multitude of specific-use applications.
Development of such a platform is not trivial, and Apple have put great effort into making theirs a seamless experience. Similarly, GaaP cannot just be developed at random – an architecture is required. Without a disciplined approach to platform development, GaaP will be doomed to fail.
However, if done properly, with appropriate engagement, participation and collaboration with all stakeholders, the prizes are great.
For GaaP to become a reality, the Government needs to facilitate as broad a conversation as possible. This should include policy makers, central government, departments, local authorities, and the supply community.
There are many ways to enable the conversation, but a Special Interest Group supported by social media would be a good start. It will be vital to ensure a full and frank discussion takes place to cover the required technical details, and the experience of their application.
A key output from this discussion should be an agreed, common set of technical and data standards, and guidance on their implementation. Alongside this, the decisions reached must be communicated to those working to develop services across government and the supplier base.
There are many more issues – technical, business and social – in the provision of public services but, without getting the ‘plumbing’ right, we will not have the opportunity or basis upon which we can address them. Guidance and Architecture are important foundations and it is worth the initial effort to develop them.
Done right, they can provide a basis for ongoing iterative development of public sector systems, and continued and growing savings.
For more detail…
The points in this post are expanded in my paper “Some Considerations for Implementing Government as a Platform”.
Nigel is Enterprise Architect for Public Sector at Fujitsu and a founder Fujitsu Fellow. As a Fellow, Nigel helps to lead the Fujitsu Distinguished Engineer programme. You can follow him on Twitter: @NigGreenawayIT