Shared government platforms

This is a brief history of UK government initiatives over the past few decades to develop shared, cross-government technology platforms.

This overview draws upon my Digital Government and e-Government Archives, together with some other public domain sources. The archives are continuing to grow so my aim here is to help provide additional context on the use of shared platforms. It isn’t comprehensive, but aims to provide a flavour of the key developments and policies over the past 20 or so years. It’ll be updated and improved from time to time.

What is a platform?

For those not sure what is meant by the term “platform” in this context, it’s a set of core technology components created by an owner (organisations such as Apple, Google, Netflix, eBay) together with a wide range of external participants, both organisations and individuals, who complement the platform with applications and services that provide solutions that enhance and extend those created by the original platform owner.

Think, for example, of Apple’s App Store and the way it has enabled the flowering of millions of new apps. It is the shared plumbing of the internet that has enabled this platform-based transformation, letting organisations reconfigure their interactions with customers and suppliers to improve financial and operational performance. It has also fostered entirely new businesses, many of whom have replaced old incumbents – think for example of the way Netflix displaced Blockbuster.

Whilst platforms rely upon a core technical system, the technology in itself provides no value unless it also encourages successful market dynamics and a streamlined organisational form. eBay for example succeeds not because it is a technical platform, but because it makes it easy to bring together buyers and sellers (market dynamics) and offers a better way of doing so than traditional marketplaces (organisational form).

The UK government was amongst the first to adopt the use of platforms as it moved to put services online on the internet. This work broadly falls into two main phases: the period from around 1998 through to around 2010; and the period from 2010 onwards.

Both of these periods, whether by accident or design, identified similar platforms for use across government. This includes systems able to support common services such as the identification and authentication of users, payments to government, notifications or alerts (for example to update someone of the status of an application), and other similar elements required by a wide mix of services.

Overview

It was realised early on in the move to put public sector information and services online that many of them have similar requirements. This led to the idea of developing shared platforms – technology services 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 parallel system, as had been 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, instead there would be a pan-government way of letting users set up a user ID and password, one that could be re-used for any online government service. This common requirement was the rationale for the creation of the Government Gateway (see the summary on “Online Identity” for more details in this specific area).

In 1998, the Parliamentary Office of Science and Technology (POST) had 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:

Option Description
Business as usual Departments and agencies could continue to adopt IT to meet their own needs on an independent basis
Improved co-ordination Government 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-engineering Government could be re-engineered around common processes

POST considered several approaches to how the re-engineering of government services might best be achieved, with the most radical approach being to follow the example set by leading businesses and to re-engineer government departments and agencies around common processes. The critical issues POST considered relate to 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.

The initial UK government approach to development of more joined-up services was set out in the 1999 Portal Feasibility Study. It proposed the three-tier architecture set out below.

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

This architecture 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 a host of common components could be developed that all online public services could draw upon, 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 and the initial implementation of cross-government platforms

From late 2000 onwards, the UK government built out a series of common, cross-government platforms. There was a clear business case for taking this “whole of government” approach: it was already evident that without some degree of common services, each part of the public sector would proceed with its own local initiatives — from websites to identity systems to payments systems and so on. The same needs would be met time and again in multiple places, resulting in pointlessly duplicated expenditure, processes and systems.

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 initial shared platforms implemented from 2000 onwards were:

  • Cross-government website: the earlier work from 1994, which had seen the launch of the Government Information Service (1994), was in 2001 replaced with a cross-government website UKonline and then by Directgov in 2004 along with a site for businesses known as BusinessLink
  • Registration & Enrolment: the identification, authentication and verification of online users — citizens, businesses and intermediaries — utilising a range of credentials, from user ID and passwords to digital certificates to — later — EMV chip and PIN cards
  • Transaction Engine: handling the processing of transactions between citizens, businesses and departments, including the management of state and orchestration across multiple service providers where a transaction involved multiple entities
  • Secure Messaging: handling two-way secure communication between departments and citizens
  • Payments Engine: handling in-bound payments to government departments
  • Helpdesk: an internal service enabling departments to integrate a degree of 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 taking this common, cross-government approach was explained 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.”

[Source: “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]

The provision of common platform components avoids duplication of the same needs across multiple government services. It came about, in part, because each department was developing its own local solutions to its online service needs, with a resulting duplication of expenditure and fragmentation of services from a user perspective. Moving to a strategic, platform-based approach for common services made sense from an economic, architectural and user experience perspective.

From the start, all of the technical standards used were stipulated by government to be open, enabling interoperability regardless of the software or vendors involved across the many connecting organisations:

“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.”

[Source: 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 the initial cross-government components, in 2003 a further set of services began to be developed.

2003 components
Existing and proposed cross-government platforms, 2003

Despite the general agreement on the principle of shared platforms, internal issues relating to funding and agreement between the multiple stakeholders involved became increasingly problematic. 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 then as it is now. Despite the availability of additional platforms such as the Notifications service, many organisations and departments continued to develop their own alternatives rather than making use of the common platforms. The technology-based approach to shared provision found itself cutting across the political and management structures of the organisations involved.

The longer term aim was to help use technology to implement a re-engineering of government that would in turn enable its more effective reconfiguration and redesign around citizens, businesses and frontline workers. The high level vision of how this could be achieved through a series of shared 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 latest platforms

In 2010, “Better for Less”, which set out many of the ideas implemented in government during the 2010-2015 period, drew on the experiences of implementing cross-government platforms to emphasise 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.

In 2013, the Government Digital Service (GDS) published in its Service Design Manual its intention to continue this journey towards what had became termed “Government as a Platform” (after the 2009 vision of Tim O’Reilly). The text initially published by GDS for their Government as a Platform vision has subsequently been removed from the site, but is still viewable in GitHub here. It recognised the need to work smartly including:

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.

Another announcement about this commitment was made in September 2014 by Sir Jeremy Heywood, Cabinet Secretary and Head of the Civil Service, in a blog entitled “More than just websites“. This suggests that the move towards a platform-based model, underway since the late 1990s, has become more generally accepted, not only at the engineering level but, as importantly, at the business and services level too.

Current status

Current systems in use include a blend of platforms built during the period 2000-onwards as well as since the general election of 2010. These include:

  • Cross-government website: the latest incarnation of the earlier common website initiatives – the Government Information Service (1994), UKonline (2001), Directgov (2004) and BusinessLink – is now GOV.UK (2012). There is no longer a dedicated business website.
  • Registration & Enrolment: the identification, authentication and verification of online users. Alongside the continuing use of the 2001 Government Gateway, which supports citizens, businesses and intermediaries, there is also now the GOV.UK Verify hub, which uses third parties to identify citizens, as well as a variety of other approaches in local government and the NHS, for example.
  • 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 preferred current approach to cross-government transaction handling and authentication is unclear, including any migration from the 2001 Government Gateway.
  • Payments: handling in-bound payments to government departments. The original payments platform appears to no longer be in use, and a replacement has been developed as a beta by GDS, known as GOV.UK Pay.
  • Notifications: the original notifications service appears to no longer be in use, and has been replaced by the beta of a new GOV.UK Notify service developed by GDS.

Summary

The role of platforms has been a key part of the UK government’s approach to moving online 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, 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.

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

As the original platform guidance published by GDS sensibly 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 an earlier Cabinet Office team were captured in a 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 had 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)

It remains to be seen how well the latest iteration of platform-based solutions and services will succeed. One possible source of encouragement is the fact that some of the platforms built in 2001 are still in live use across government for millions of users – which suggests that the right platform solving the right problem at the right time can succeed.

Advertisements