high level cross-government architecture — 2003 style

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.

online service vision 2003

The high level architecture behind this vision is shown below.

conceptual x-government viewIt’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.

x-govt conceptual more detailed

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

backend integrationThis 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.

backend transition

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.

x-govt orchestrationAn 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.

common components A more detailed breakdown of the layers of the model is shown below.

detailed layers

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.

GG enablers

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.

Advertisements

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s