This is the second part of an ongoing, occasional series looking back over the past 20 years or so of UK efforts to move government online.
In Part 1, I provided a very brief summary of progress towards a single online presence. It looked at the “front-end” of online government — the thinking around a “portal” or single website to act as a “one stop shop” for all digital government services. This helped set a context for Part 2, in which I’ll now provide a similar high-level summary of the overall architectural thinking, of which the portal/website was but one component. As before, this will only skim the surface — but hopefully provides a useful overview of what has gone before.
The open.gov.uk site established in 1994, and outlined in Part 1, was the first step in the evolution of a planned, pan-government architecture. The 1999 Portal Feasibilty Study which built upon this early work identified the need for an architecture to insulate access channels from complexity, proposing a three-tier architecture that would achieve this whilst also providing flexibility. This conceptual model is illustrated below (clicking on any illustration will enlarge it).
Whilst the various front-end channels were to be supported through the portal/website developments outlined in Part 1 (providing publication and syndication services), transaction management services (including related services, such as the identification, authentication and verification of users) were to be provided by a second tier — the services that collectively became known as the Government Gateway. This provided the middle tier, handling the orchestration and management of transactions across single or multiple backend departmental services.
As the report described it, the third tier:
“… provides the connectivity from the Departmental systems, including legacy systems, to the Transaction Management System through appropriate interface systems. This layer will “ring fence” existing systems. Its isolation layer will allow ongoing development of the Departmental systems without a knock-on development requirement on the Portal architecture.”
The report also emphasised the importance of open standards in ensuring that the three tier model was to provide the flexibility in terms of security scalability and resilience required of online service delivery:
“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.”
The physical architecture set out by the report to deliver this is shown below.
(For those not familiar with the acronym, ‘GSI’ was the Government Secure Intranet, now superseded by the PSN — Public Sector Network. This is an internal, secure network for private government-internal use only).
The importance of being able to identify a citizen or business when they are online has long been recognised as critical to the success and viability of any online public services. At the time, many smart card developments were in progress, such as Royal Mail’s ViaCode and Barclays Bank Endorse initiatives. The report recommended that “Public Key Infrastructure (PKI) should be provided using certificates and certificate authority solutions from companies such as VeriSign, Thawte or a retail Bank.”
Whilst the front-end services were delivered through the various developments outlined in Part 1, the middle tier component was provided by the Government Gateway. This was designed to provide support via open standards interfaces both for the orchestration of transactions, and for federated identification and authentication services provided by third parties via smart cards — as this press release from Barclays from around 1999 makes clear. However, the smart card market largely collapsed in the dotcom boom and bust, and the middle tier defaulted instead primarily to a User ID and password system, with a few businesses continuing to use smart cards for a number of years. These services were later supplemented through support for EMV (the chip and PIN standard developed by Europay, MasterCard and Visa and widely used for for authenticating credit and debit card transactions). However, by far the largest method used was that of User ID and passwords, with the original federated identity model unrealised on any scale.
The middle tier was designed around the use of XML (the eXtensible Markup Language) and SOAP (the Simple Object Access Protocol), and drew upon other internet-based standards such as HTTP/S. Since there were no standard “off the shelf” patterns or templates at the time for the orchestration work required of the middle tier and its interaction both with backend departments and the front-end portal, the necessary XML and SOAP interactions were defined under the “GovTalk” banner, as part of the e-Government Interoperability Framework (e-GIF) initiative which aimed to bring public and private sectors together to agree the open standards necessary to deliver vendor-independent solutions for online government services. Possibly today much of this model would be constructed using JSON (JavaScript Object Notation) and RESTful (representational state transfer) solutions in place of the often rather verbose XML and SOAP requirements. It would also probably avoid the need for the “central hub” model, and provide more of a peer-to-peer services-based approach, such as that adopted by the Estonian government and its X-Road initiative.
By 2004, the overall architecture was looking broadly like the schematic below.
In addition to the original core middle tier services of identity and transaction handling, additional service components — such as a payments engine and secure messaging (similar to the kind used for banks to communicate securely online with their customers) — had also been added. The ‘Gateway DIS’ function was the departmental integration service (hence ‘DIS’), providing the bridge between the open standards (XML, SOAP etc) being used in the middle and front-end tiers, and whatever proprietary or bespoke requirements needed to be met within the departments’ existing IT systems estate.
This architectural model remained largely the same over the intervening years. Its open interfaces and specifications enabled, for example, payroll providers to embed support for online government transactions directly inside their applications, automating the interaction of business with government across both authentication and transaction handling systems.
In the meantime, and as I described in my piece for the Register “Can the UK have its identity strategy back, Mr President?” in 2009, the USA adapted the earlier UK federated identification and authorisation model. In turn, the UK has been actively revisiting the desire to move back to a federated identity model as originally foreseen in the late 1990s and away from the dependency on the much-criticised and user unfriendly User ID and password system of the Government Gateway. The Government Digital Service (GDS) has usefully summarised current work on implementing a new federated identity service in their recent blog post “What is identity assurance?”
The middle tier is now in its twilight years, with the Government Gateway due to be terminated around 2016. Given the many changes in technology since the late 1990s, together with the implementation of more up-to-date technology practices within government on the back of the work of GDS, many elements of the overall design of online public services are currently in motion to update the UK’s digital public infrastructure. They will doubtless build upon the recent work to embed open standards in government, the replatforming of gov.uk, the ID Assurance programme, and the work on the 25 exemplars — all within the guiding framework of the Service Design Manual.
The work of Simon Wardley, and his Wardley maps, are of pragmatic significance in the current debate about how “special” or “unique” government is in its user and technical needs, and how they can best be met. As Simon points out, “… the maps cover activities, practices and data and aren’t limited to a specific field such as technology. They can be used to identify common services, differences, areas of efficiency, potential strategic gameplay, solve communication issues and … a long list.” Even in a complex area such as taxation or welfare, breaking down the needs and the potential means of meeting them quickly reveals that a wide range of both utility and product elements can help meet those needs, with only a small core — such as the nature of the rules of calculations to be conducted — being the unique, one-off elements required in the realisation of UK-specific policy.
There have been multiple detailed analyses and inquiries into the problems of closing the long-standing gap between political aspiration for better public services and meaningful, sustainable delivery on the ground — such as those of the National Audit Office and the House of Commons Public Administration Select Committee. The problems encountered have rarely been exclusively technical — after all, the architectural approaches of the past, described above, would not look particularly out of place in a private sector organisation over the same time period. I’ll aim to review and comment upon some of the wider work analysing the causes of this long-standing gap, and current and earlier work that aimed to fix it, in a future post.
Update: Part 3, approaches to identity, is now available
New tech observations from the UK (ntouk) 