I tweeted recently a couple of old IT architectural schematics from 2003. They provide an interesting (historical) perspective on how to bring existing government systems into the world of online services.
Following a few requests, I thought I might as well follow-up by blogging in a bit more detail about those schematics here — given the subject remains highly topical.
Back in 2003, the aim was to reach consensus on a cross-government technical architecture that would provide the right balance between centrally provided and department provided components. In 2003, the open standards of e-GIF (the e-Government Interoperability Framework) prevailed and the default data format for inter-system interoperability was XML (the extensible Markup Language).
The “Vision” from 2003 is shown below.
The high level architecture behind this vision is shown below.
It’s fairly self-explanatory at this level — with several core elements shown down the righthand side (management and operations; data interoperability [XML]; security framework; metadata framework), and four key technical layers to the left: data sources; data access; business, logic and workflow; and UI components and processes.
This is expanded a little more in the view that follows.
The top tier makes clear the multi-channel strategy and the way government services were envisaged as being delivered through a whole range of different organisations: from government to businesses to the voluntary sector, and through a variety of devices.
Web services were to provide the common, open standards for how the various online government services could be delivered via public interfaces. At the “common services” tier a range of modular components (from authentication to payments to notifications) were to exist, providing a flexible way of pulling common components together in the design of frontline services. Behind this, a similar open layer of web services existed which would use XML to proprietary integration mechanisms to connect into existing systems — be they public or private sector — needed in the design and delivery of online services.
For this approach to work, both departments and the centre needed to agree standards for the web services to be exposed by departments. The integration between XML and existing systems — to enable that integration — also needed to be resolved to ensure consistent delivery. There would need to be a way of reliably orchestrating processes both at the central government level (for cross-government orchestration of multi-departmental services) and at the department level (cross-system).
At the centre, the Government Gateway (which became an umbrella term for a range of component services — primarily identity and authentication, transaction orchestration, payments, and departmental integration services), acted as a broker, ensuring all calls were made through the same common architecture and endpoints. This included defining common standards in areas such as naming conventions, error handling responses and so on, together with the XML schema, meta content etc of the actual SOAP (Simple Object Access Protocol) methods and calls used for the interaction of content and services.
At what has often proved the most intractable and complex layer — that of bridging the gap between existing systems and online services — three elements came into play:
- custom adaptors (specific integration tools for e.g. a mainframe)
- web services interfaces surfaced via the adaptors and exposing data and methods through native XML/SOAP
- associated process logic to ensure data and application integrity
This approach enabled a variety of existing systems to be bridged into the open, web services world. Of course, this was meant to be a transitive stage and not something to fossilise and preserve existing systems, enabling them to live on forever. It was intended to be a pragmatic way of taking early benefits in a massively diverse brownfield environment whilst a parallel programme could begin to re-engineer and re-architect backend processes, data, systems and their owning organisations into something better suited to twenty-first century government services.
This secondary stage foresaw the assessment, transformation, re-factoring and web-enablement of these older systems — with an end goal of removing older backend systems and disaggregating and componentising them to enable departments to redesign and improve their services free of the restrictions of their inherited IT estate.
The illustration below shows conceptually how this architectural approach would enable the central orchestration of a service across multiple departments, with each of those departments in turn tackling local integration across their multiple backend systems.
An alternative view of the central components/local integration model is shown below, illustrating the role of common, re-usable components in the overall architecture and service design model.
A more detailed breakdown of the layers of the model is shown below.
Returning to a higher level perspective, the schematic below shows how the various components comprising the Government Gateway provided the realisation of some of this vision.
Note the existence of a “virtual department” to the right of the picture: this was a major concept at the time. Rather than trying to fix all of the historic issues of existing systems, data, processes and organisational hierarchies, the proposition was to create ‘virtual departments’ that would provide a way of exposing new services built around citizens’ and businesses’ needs rather than merely projecting the existing departmental service structures onto the internet. These would enable the development and design of better services — but, over time, they would also build out the future of government, at which point the existing systems could be switched off. More ambitiously, they would also enable the potential reconfiguration of government itself as it would no longer be tied down by information systems that had fossilised the historic business units and hierarchical functional silos of the departments and agencies in which they had been designed and deployed.
Some 11 years on, there remains considerable healthy debate about the best architectural models for government — across business, information and technical levels, and indeed the wider organisational configuration of government itself. At the polar extremes are opposing technical perspectives on the merits of emergent solutions and approaches versus imposed blueprints, and of centralised versus federated models.
As with most of these things, neither extreme in itself will prevail: good systems, successful technology and well-designed user services tend to involve a shifting blend of models and approaches. But hopefully I’m not alone in finding it useful to document the journey we’re on — and the road already travelled.
New tech observations from the UK (ntouk) 