Skip to content

Report of the Digital Government Review

Reducing Cost with an Open Digital Architecture

So far, there is one comment on this section. Jump to comments

Introduction: the current state of government digital architecture

The diagram below shows the current published “reference model” for government architecture [135].

Figure 6 – government architecture reference model

Figure 6 – government architecture reference model

On the page where it is published this diagram is described as illustrative, and there are some fine words describing what an architecture should be, but there is no other published model. This does not represent a coherent or detailed model of systems architecture.

A systems architecture should offer a clear formal representation of the different components in a system, describing their precise relationships and hierarchy – and enabling new products and systems to be developed easily and compatibly with existing systems and their processes.

The diagram above, in these terms, can be seen to be incomplete and significantly lacking in detail. It is primarily focused on technical elements, for example, excluding both process and data components. Its pyramidal structure is meaningless: it could equally be re-drawn as a square, circle or star without loss. It offers little meaningful information to those seeking to understand the common principles underpinning public digital services.

Compare this diagram from the 1990s of Technical Architecture Framework for Information Management (figure 7), which – as any diagram of systems architecture should – displays clear relationships between all the distinct components comprising a particular system:

Given the inadequacy of the current approach to systems architecture, it is little wonder that so much open public data varies in format – making it needlessly difficult to compare and combine – or that geospatial data, which number among the most important of all public data sets, is not available as open data at all. No one knows how the data is produced, its provenance, how it is processed, where it is stored, who has access and where it is published.

This inadequate approach is also one of the reasons why different organisations serving public needs operate in silos and struggle, at a technical level, to integrate services, and to share data (with the right principles and methodology). It is why the government finds it hard to switch suppliers at the end of a contract: what interfaces does the old system support, how is it integrated, how does it function?

Figure 7 – Technical Architecture Framework for Information Management

Figure 7 – Technical Architecture Framework for Information Management

None of this should be news. The current government has itself realised that it has moved too slowly on defining architecture, on opening up APIs and on moving towards a common platform with reusable components. During the life of the review this was recognised by both the Cabinet Office [136] and the Head of the Civil Service [137]. The key question, though, is how precisely a properly defined open digital architecture can change this – and what obstacles and complexities lie in the way.

“We agree that taking a component (or modular) and service-neutral approach is the appropriate way to drive transformation of service delivery…. Open standards are essential for a component-based approach to work.” – Local Authority


This page reformats automatically when printed. Print this section

Leave a Reply to Jeremy Viner Cancel reply

Please note that comments left here are public - you can also make a private submission.

Your email address will not be published. Name, email address and comment are required fields. Please note we may moderate comments.

One comment

  1. Jeremy Viner says:

    In order to implement and govern effective initiatives and cost-effectiveness, good Enterprise Architecture is necessary.

    As such, as well as delivering a suitable governance framework, I recommend a focus on Business Architecture, clarifying the services required over time and an analysis of the data and services across all functions with a view to consolidation of services where possible.

    This must be initiated prior to any Technical Architecture activity.