Comparison of Major Messaging Sub-Systems in the UK Government

Leave a Reply

This is the second part of a three part overview of UK Government G2G Messaging Sub-Systems.

Specifically this post is a “Comparison of Major Messaging Sub-Systems in the UK Government”, looking in more detail at three of the largest UK G2G systems and contrasting them with each other.

I’ve split it into two parts:

Comparison of the major Identity Ontologies

I’ve found that for any of these systems to truly deliver significant value they need to support four basic components. In fact this is no different of any large integration system found in any other sector. The four basic building block are:

  • Internal (Back-End) Integration – preferably “Service” focused, there has to be a way to unlock the functionality and processing capability within the individual departments, organisations and authorities. Whether this is via a “Service Oriented Architecture” (SOA) or “Enterprise Application Integration” (EAI) a fundamental premise is that data can be sent and received from these “Back-End” systems.
  • Shared Identity – An Ontology wide shared understanding of Identity is required for these disparate systems to share data and function with the correct level of authority.
  • Messaging System / Backbone – An Ontology wide & inclusive G2G messaging system – unlike the internal messaging systems used within Departments, Organisations and Authorities (typically under one management team and are “closed systems”), the G2G systems are typically outside any single organisations monopolistic control, requiring participation from the wider membership of that Ontology to deliver data communication across it’s members.
  • Access (Front-End) Gateway(s) – Portal or other Front-End access point – visibly delivers much of the value, which is actually brought into being by the previous three building blocks.

Table comparing the major Identity Ontologies

The table below shows each of the Ontologies I had identified in my earlier post, and rates them across the four areas described above.

  Silobusters / Internal Integration Common Ontology Wide Identity G2G Messaging Subsystem(s) Access Gateways Other Notes
Citizen Some Internal Integration – not yet focused upon the real-time provision of services Yes – via the Government Gateway Yes – via the Government Gateway Mostly Organisation specific, some centralisation – via the Government Gateway Only Ontology heavily in production – Hub & Spoke Model
Justice Little or no Internal Integration None Defined / Agreed Three Major messaging systems evolving – CJEX, Impact & DISC – natural segregation of case information Mostly Organisation specific, very little centralisation (mapping to messaging systems) Triple Hub Model evolving – Based around Data Segregation (“data firewalls” likely to be required)
Immigration None we are aware of (Little or no Internal Integration) None – would heavily be based on Passport data for early revisions None – Was due to have a single link to Police ‘Schengen’ Systems, however this has paused, as has our implementation of Schengen Organisation specific  
Transport None we are aware of (Little or no Internal Integration) None – would heavily be based on Driving License data for early
revisions		 None we are aware of Organisation specific  
Health Brownfield Integration at the Local Service Provider (LSP) level slowing – more
research needed		 Some – evolving based around ‘Patient’ data NHS Data Spine – 5 Sub-Hubs at the LSP – a Star Hub Model   Hub & 5 Sub-Hubs Model (Star Model)
Security None we are aware of (Little or no Internal Integration) Unknown by Author SCOPE – No Data – Assume some inclusion of G2G type functionality Unknown – Organisation specific ?  
Military None we are aware of (Little or no Internal Integration) Unknown by Author DII – No Data – Assume some inclusion of G2G type functionality Unknown – Organisation specific ?  
Education None we are aware of (Little or no Internal Integration) Unknown by Author Currently under investigation Mostly Organisation specific, very little centralisation  
Other(s)         Fire Service ?

If you can help fill out this table – then kindly get in touch (preferably via the “comment” mechanism at the bottom of this post) and I’ll be happy to republish with suggested amendments.

With hindsight what I feel that what I should have done with this table is break the Ontologies down into their constituent members – especially when looking at how much internal integration has been and is being planned to be delivered in the near future.

Comparison of three of the largest UK G2G systems

Now I’ll be looking in more detail at three major Messaging subsystems, and comparing them against each other.

The three major G2G messaging systems in government are:

The Government Gateway, the NHS Data SPINE and the Criminal Justice Exchanges

UK-G2G-Systems-0.1.9

This diagram shows the three major G2G areas that we identified above: it allows us to see each of them in contrast to the other – hopefully making the differences more pointed (and thus more obvious).

The (Single) Hub & Spoke model used by the Government Gateway

Shows the “Hub & Spoke” used by the Government Gateway.

UK-G2G-Systems-0.1.10

Notable points:

  • The Gateway has to be Highly Available – or nothing Communicates if it’s down
  • The Sub-Spokes shown communicating into Local Authorities actually just pass traffic straight through to the Government Gateway – there is no way to keep traffic within a ‘Sub-Hub’ – all traffic terminates, originates, or passes through the central ‘Hub’
  • Relies upon a DIS box as an end point – this acts a “Guaranteed Delivery” mechanism as once on a DIS box the traffic is assumed will (eventually) arrive at the central Hub

Five Point “Star Hub” Model used by the NHS NPfIT Data SPINE

Shows the “Star Hub” used by the NHS NPfIT Data SPINE.

UK-G2G-Systems-0.1.11

Notable points:

  • The model implies that if the central hub is unavailable end-points (hospitals, LHA / LHB’s) connected to a Local Service Provider (LSP) will still be able to send and receive data with their Regional Siblings
  • Of course we now have 6 messaging systems, with almost identical functionality (apart from the Authorisation and Authentication, and the Registration and Enrolment).
  • The diagram is slightly incomplete as it’s likely that Hospitals, etc, would plug into the LHA / LHB’s for a region – who would then in turn plug into the Regional LSP

“Tri-Hub” model currently evolving within the (Criminal) Justice Ontology

Shows the “Tri-Hub” developing in the Home Office / (Criminal) Justice Ontology.

UK-G2G-Systems-0.1.12

Notable points:

  • Although this has evolved out of exasperation (with Centralised Functions, like the CJIT Exchange) – it actually makes a lot of sense
  • It allows for data communications between like for like organisations, but logical & physical segregation between the Courts, etc. & the Police, etc. & the Home Office / NOMS, etc.
  • I believe that ‘information firewalls’ will evolve to segregate (and keep secure) information between these three primary groups – the Police & Courts can not share certain case information – it’s possible they can be aware it exists, but not the content – this model allows for ‘localised’ sharing, but secure within a group
  • The model also implies that by having no central hub means it is more resilient – end-points will still be able to send and receive data with their Group Siblings – as well as having dual resilient routes

That completes part two of my overview of UK Government G2G Messaging Sub-Systems.

Again come back in a couple of days for the next instalment – the “Evolution of Messaging Sub-Systems used by the UK Government” – given the current, and the near-future, state of UK G2G systems, how might we expect them to mature and evolve.

Part one of this article, “Messaging Sub-Systems in the UK Government”, is also available.