Shared, cross-government platforms

This is a brief overview of UK government initiatives to develop shared, cross-government platforms over recent decades.

It draws on my Digital Government and e-Government Archives, together with other public domain sources. The archives continue to grow so I thought it’d be useful to provide additional context on the use of cross-government platforms. It’s not comprehensive, but aims to provide a flavour of developments and policies over the past 20+ years. It’ll be updated and improved from time to time – so your feedback is always welcome.


What is a ‘platform’?

For those not sure what’s meant by “platform”, it’s a set of core technology components created by an owner that provide a re-usable base upon which other services, applications, processes or technologies are developed. Much of the success of organisations such as Apple, Google, Amazon, Uber, Airbnb, eBay is a result of their creation of widely used platforms.

Think, for example, of eBay. It provides a platform that makes it easy to bring together buyers and sellers, and offers a better way of doing so than traditional marketplaces – on a scale and with an efficiency previously almost unimaginable.

The shared plumbing of the internet has enabled this platform-based transformation, letting organisations reconfigure their interactions with customers and suppliers to radically improve services as well as financial and operational performance. It’s also fostered entirely new businesses, many of whom have challenged or even replaced old incumbents – think for example of the way Netflix displaced Blockbuster.

The UK Government was a platform pioneer

The UK Government was amongst the first to understand the potential of platforms in the design and delivery of public services – to improve how public service providers and users could interact with each other.

Innovative early work by the Cabinet Office’s Central IT Unit (CITU) in the late 1990s placed the use of platforms at the centre of its approach as government moved to put information and services online. Ever since, various cross-government initiatives – under, for example, the Office of the e-Envoy and the e-Delivery Team (eDT), and more recently the Government Digital Service (GDS) – have placed re-usable, cross-government platforms at the centre of the UK’s approach. These include platforms providing services such as the identification and authentication of users, payments to government, and outbound notifications (for example, emails or text messages to update someone of the status of an application or government process).

The need for government platforms

Early on in the move to put public sector information and services online it was recognised that many have similar requirements. This led to the idea of developing shared platforms – technology that could be implemented once and then re-used many times across organisations and services, rather than each organisation and service creating its own duplicate system (as was the case in the pre-internet era).

For example, rather than each online government service setting up its own local user ID and password system, there would instead be a cross-government way of letting users create a user ID and password, one that could be re-used for any online government service, central or local. This common requirement was the rationale for the creation of the Government Gateway Registration and Enrolment (R&E) platform, which provided user identification and authentication (see “Online Identity” for more details).

Similarly, the other core Government Gateway-branded platform at launch in 2001, the Transaction Engine, enabled the provision and orchestration of online services, processes and transactions, including those spanning multiple departments and requiring state management (because of the different timescales in which departments or processes might respond). Data could be acquired once – for example via a smart online form, or from an existing data source in a department – and then used across multiple silos. This enabled the delivery of “joined-up” services to users, regardless of how complex the underlying systems and processes might be, spread across multiple systems and departments. The use of the R&E platform ensured the appropriate level of identity and authentication assurance was applied to transactions.

1994 onwards and the development of platform thinking

Arguably, the UK’s early cross-government website, the rather formally named “CCTA Government Information Service” hosted at open.gov.uk, was the first attempt to use a common platform. Launched in 1994, by 1996 it had brought together information from 180 public sector organisations, 79 of which were hosted on the central platform itself.

In 1998, the Parliamentary Office of Science and Technology (POST) considered the impact of technology on government and its services in an holistic way. Their report on “electronic government” included the following schematic as part of a discussion about common processes across government.

POST gubbins
A 1998 view of common services (source: “Electronic Government”, POST)

The POST report outlined several IT-enabled options for the future, an adapted form of which is shown below:

OptionDescription
Business as usualDepartments and agencies could continue to adopt IT to meet their own needs on an independent basis
Improved co-ordinationGovernment could seek to achieve better co-ordination and use of resources between departments and agencies through joint implementation of IT projects such as ‘one stop shops’ for small businesses, enabling Government to appear ‘holistic’ from the outside but without a significant impact on departments’ and agencies’ current working models
Re-engineeringGovernment could be re-engineered around common processes

POST considered several approaches to the re-engineering of government services, with the most radical being to follow the example set by leading businesses: to re-engineer government departments and agencies around common processes. POST considered the scope of such a transformative change – whether it should be applied within existing departmental boundaries, across the whole of central Government, or spread wider to include other public and/or private bodies. They also considered the basis of such re-organisational models: whether, for example, services should be remodelled along process lines or orientated around citizens’ needs associated with life events, such as getting married or having a baby.

Open platforms and “joined-up” services

The initial UK Government approach to designing and delivering more joined-up services was set out in the 1999 Portal Feasibility Study. It proposed a three-tier architecture:

3 tier conceptual architecture
The 3-tier approach adopted from 1999 onwards (source: “Portal Feasibility Study”)

This approach was designed to support a wide range of access channels, and to enable the existing IT estates of departments and agencies to integrate without requiring a big bang, “rip and replace” approach. It proposed that:

A three-tier architecture can be used to insulate the access channels from the complexity of the Government Back Office with web technology providing the portal, or gateway between the channels and the individual service requested. The key concept of the three tier architecture is the use of middleware technology to provide a brokerage capability, a concept that sits well with the idea of a portal. The middleware will link components to allow them to interact without the need to have knowledge of the other component’s location, hardware platform, or implementation technology.

p.7

The middleware tier was where common platforms could be developed for all online public services, rather than each implementing their own. As part of this approach, the importance of open standards was recognised:

The technical implementation of the three-tier architecture must provide the glue to link existing Departmental services and systems to a wide range of different access channel technologies. This means that open standards need to be proscribed and that the interface standards needed to ensure good interworking must be defined.

An open architecture will maximise the flexibility and opportunities for infrastructure provider competition. Every major interface in the architecture will need to have an interface specification defined for it. This will allow architectural components, services and supplier systems to be replaced easily and a ‘plug and play’approach to be taken to architecture components, services and supplier systems.

p.8

2000 onwards and the implementation of multiple cross-government platforms

From late 2000 onwards, the UK Government created a series of shared cross-government platforms.

The business case for taking this “whole of government” approach was well understood: without common services, each part of the public sector would proceed with its own local initiatives — from websites to identity to payments and so on. This would not only be expensive, and duplicate common infrastructure in multiple places across the sector, but also produce a poor user experience: government services would be scattered across a technological landscape that replicated the physical world of multiple overlapping and siloed providers. Leaving everyone to do their own thing would effectively fossilise existing, paper-based services and organisational structures in the online world rather than taking the opportunity to improve and streamline them – as well as adding to the cost and inconvenience.

The vision in 2001 – bringing all government information and services together onto cross-government platforms and providing integrated (“joined-up”) services, including through life episodes [source: The Grand Plan V3.3. 2002. e-Delivery Team, Office of the e-Envoy, Cabinet Office]

The initial cross-government platforms implemented from 2000 onwards all used open standards and open APIs. They were:

  • Central website: the earlier work from 1994, which had seen the launch of the Government Information Service, was in 2001 replaced with a cross-government website UKonline and then by Directgov in 2004 along with the BusinessLink site to meet business needs
  • Registration and Enrolment: the identification, authentication and verification of online users — citizens, businesses and intermediaries (people with authority to act on behalf of someone else) — utilising a range of credentials, from user ID and passwords to digital certificates to — later — EMV chip and PIN cards
  • Transaction Engine: orchestrating the processing of transactions between citizens and government, businesses and government, and between departments. This included the management of state across multiple service providers where a transaction involved multiple government departments and agencies — this enabled the design and delivery of joined-up services for users (on the website and through application software using open interfaces) even where existing systems and processes were still siloed in multiple departments
  • Secure Messaging: handling two-way secure communication between departments and citizens (similar to the way many banks provide secure online messaging on their websites)
  • Payments Engine: handling in-bound payments to government departments
  • Helpdesk: an internal service enabling departments to integrate management of these common components services within their existing helpdesk services

These cross-government platforms are illustrated in the schematic below.

components
The cross-government platforms implemented from 2000 onwards (source: Jerry Fishenden)

The justification for this approach was explained in 2003 as follows:

“[this approach] was designed to simplify and accelerate the UK e-Government programme. It achieves this by ensuring that the common building-block components of e-Government services are provided once, in a flexible, modular and scalable way.”

“Delivering e-Government Services to Citizens and Businesses: The Government Gateway Concept”. Jan Sebek, p.127. Published in “Electronic Government: Second International Conference, EGOV 2003, Volume 2”. Editor Roland Traunmüller

By adopting the use of platforms since the early 2000s, the UK Government avoided both the fragmentation of users’ experiences and duplication across multiple government services. Moving to a collaborative, platform-based approach for common services made sense from an economic, architectural, service and user experience perspective.

UK Government Platforms, 2004 (‘e-Government, the UK and the wider e-Government landscape’. March 2004)

The technical standards used were required to be open, enabling interoperability regardless of the software, technologies or vendors involved across the many connecting organisations, leading in 2006 to:

international recognition of outstanding work around open, interoperable authentication in the e-government sector.

Liberty Alliance, IDDY Awards, 2006

The following year a European study identified the benefits of the UK Government’s approach, including interoperability between a wide range of vendors and technologies:

“A wide range of systems have interoperated with the Government Gateway since its launch, including systems running Sun’s J2EE technology, IBM technologies, Apache, Tomcat and other technologies and applications including standalone PC application software.”

Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications NATIONAL PROFILE UK April 2007. p.16. IDABC European e-Government Services.

Additional platforms

Following on from the successful release and implementation of these initial cross-government platforms, in 2003 a further set of additional platforms began to be developed.

2003 components
Existing and proposed cross-government platforms, UK Government, 2003

The longer term intent of the platform-based approach was to use technology to implement a re-engineering of government processes and services that would enable their reconfiguration and redesign around citizens, businesses and frontline workers. In a sense, government was progessively stepping towards the type of re-engineered model set out in the POST report of 1998.

The vision of how this could be achieved through a series of shared, open standards platforms is shown in the high level schematic from 2003 below.

architecture 2003.png
2003’s view of a cross-government architecture (source: Jerry Fishenden)

The challenges of reality …

Despite general agreement on the principle of adopting shared platforms, internal issues relating to funding and agreement between multiple stakeholders became increasingly problematic. Although platforms made sense to meet notionally similar needs, competing organisational requirements and the separation of powers and responsibilities across government (often specified in law) made the notion of sharing generic services more problematic in practice than it appeared in theory.

The recurrent issue of how much government should itself try to build in-house and what it should consume or purchase from others was also as much a debating point during the early 2000s as it is now. Despite the introduction of additional cross-government platforms such as the Notifications service (enabling users to receive updates through their communication channel of choice, such as via email), many organisations and departments continued to develop their own alternatives.

The technology-based approach to shared provision found itself cutting across the political, cultural, democratic, legislative and management structures of the organisations involved.

Renewal of the platform vision

In 2009, “Better for Less” set out many of the ideas implemented in government by the Office of the Chief Technology Officer (OCTO) and GDS during the 2010-2015 period. It drew on these earlier experiences of implementing cross-government platforms to highlight the value of this approach:

The use of a common infrastructure is critical … applications must be developed to work together using open standards for data and interoperability. It is critical that the common infrastructure is available for all the identified stakeholders: officials, citizens, third sector organisations, potential and actual solution providers …

… Government IT is well placed … if it adopts this construct: service oriented architecture, open standards, re-use of components and a carefully thought-through incentivisation environment encouraging and supporting innovation and re-use. It can take advantage of a cheap, commodity platform, competitive suppliers, constant innovation, and automatic sustainability.

Better for Less. 2009.

Similarly the 2010 Transform report commissioned by the Cabinet Office’s Efficiency and Reform Group (ERG) Digital Delivery team, and UK Digital Champion Martha Lane Fox’s letter to the Minister for the Cabinet Office, helped re-emphasise the importance of open interfaces and a suite of shared web services.

In 2013, the Government Digital Service (GDS) published in its Service Design Manual its intention to continue this journey towards what had now become more widely rebadged as “Government as a Platform” (after the 2009 vision of Tim O’Reilly). The updated platform vision initially published by GDS was subsequently deleted from the site, but is still viewable in GitHub here. It recognised that:

A move to platforms does not mean that government has to develop everything in-house: many of government’s needs can be met by existing cost-efficient utility services. However, government can help to establish best practice in areas such as personal data privacy.

Wherever appropriate, the government should use existing external platforms, such as payments services (ranging from third party merchant acquirer services to the UK’s national payments infrastructure). Deciding to develop platforms in-house will happen only where that is the best way to meet users’ needs in the most flexible and cost-effective way.

Government will draw upon the experience of other organisations that have already made this journey. Many have created platforms that initially sit across the top of existing silos to expedite agile and effective digital service delivery.

This co-existence enables the benefits of the platform model to be realised quickly, even in a brownfield environment such as government, while the silos below the waterline are gradually reduced in importance and eventually made obsolete.

This is the approach that government will follow, ensuring that it develops a well-defined schedule for switching off legacy environments as the platform model is progressively implemented.

UK Government Service Design Manual, 2013. Deleted content

In September 2014, Sir Jeremy Heywood, Cabinet Secretary and Head of the Civil Service, published a blog entitled “More than just websites“. It stated that “we are increasingly focusing on an idea called Government as a Platform“.

The platform-based approach adopted in the UK since the late 1990s, was clearly undergoing a renaissance, not only at the engineering level but, as importantly, at the policy level too.

Current status (2020)

Current platforms in use by the UK Government include a blend of those built during the period 2000-onwards as well as during the period of renewed interest since the general election of 2010. These include:

  • Central website: the latest iteration of the 1990s vision to bring all of government’s services and information together in one place – the Government Information Service (1994), UKonline (2001), Directgov (2004) and BusinessLink – is now GOV.UK (2012). (There is no longer a dedicated website to meet business users’ needs).
  • Registration and Enrolment: the identification, authentication and verification of online users. Alongside the continuing use of and recent reinvestment in the original 2001 Government Gateway Registration and Enrolment platform (and related identity verification services) by HMRC, which supports citizens, businesses and intermediaries, there is also the GOV.UK Verify hub for citizens, as well as a variety of other approaches in local government and the NHS, DWP, etc.
  • Transactions: handling the processing of transactions between citizens, businesses and departments, including the management of state and orchestration across multiple service providers where a transaction involves multiple entities. The current approach to cross-government transaction handling and authentication is unclear, including whether there has been any migration from the 2001 Government Gateway Transaction Engine (there is, for example, widespread use of micro-service architectures). (Any more information on successor platform(s) or approaches to the Transaction Engine and cross-government approaches to transactions / services gratefully received!)
  • Payments: handling in-bound payments to government departments. The original payments platform has been superseded by GOV.UK Pay.
  • Notifications: handling outbound communications through a user’s preferred channel(s). The original Notifications platform has been superseded by GOV.UK Notify, one of the notable success stories from the recent platform work.

Some other new useful platforms were also developed by GDS and added to the cross-government pool, such as GovWifi and the Performance platform – although the latter appears to no longer be maintained, with many of the most recent updates being as long ago as 2017.

Summary

The role of platforms has been an integral part of the UK Government’s approach to online services since the late 1990s and continues to be a major focus today. However, in many areas the public sector continues to have multiple approaches, including around identity.

The debate also continues about how many of these platforms government should build itself, or whether it should consume products and services provided by others. This debate is hopefully being informed by the use of techniques such as Wardley mapping, which can help identify when and where a custom built versus a commodity purchase or use of say a cloud-based service makes most sense. The essential part is for government to have the capability internally to understand and make such decisions.

Screen Shot 2014-01-09 at 13.26.48-2
Wardley Mapping (courtesy Simon Wardley)

As the original platform guidance published by GDS made clear:

A move to platforms does not mean that government has to develop everything in-house: many of government’s needs can be met by existing cost-efficient utility services.

Some of the lessons learned by the Cabinet Office were captured in the 2003 paper ‘How to avoid indigestion when attempting to eat an elephant‘. They remain as relevant today for those trying to implement shared platforms in any large organisation. One of the most challenging realisations was that while the shared platforms model made sense on paper, in reality:

Nowhere to be seen, despite laudable efforts by some, is the reduction in burden, the elimination of bureaucracy or the delivery of outright cost saves – whether they be realised through reuse savings at a pure technology level or organisational savings through reduced use of existing channels.

p.3

The recent updating of some long-standing core platforms, such as HMRC’s renewed investment in the Government Gateway, along with the second generation platforms for payments and notifications, is an encouraging sign that platforms are playing a valuable role some 20+ years on from their original inception. The fact that some of the platforms foreseen, developed and improved since 2001 continue in live use across government for millions of users suggests that the right platform solving the right problem at the right time can succeed.

However, I’m also aware of the possibility that an ill-designed platform approach could potentially erode the pillars and safeguards of our democracy. Our unwritten constitution is a fragile thing. It relies upon preventing a centralisation or abuse of powers though the intentional balance achieved by splitting and distributing government into different legal entities, and ensuring that there are checks and balances between those different branches or departments. Cross-government platforms, unless well-designed both individually and collectively, could fundamentally tilt this balance – and provide a single point of oversight, power and control.

This is why it’s important that the re-engineering of government cannot, and should not, be achieved by technology and technologists alone: it needs to be politically led and subject to meaningful, transparent, open, democratic debate and scrutiny.

Last updated: May 2020. First published online 2017.