IT Spend Analysis of UK Government U-Turns in 2020 (so far)

There have been 10 UK Government U-Turns so far in 2020. Each change will have had an associated IT change cost. This is my best personal assessment of what each of these changes would likely have cost. I will provide justification for each of my assumptions and will tend towards a lower possible range. I will t-shirt size each U-turn using Low (£500k), Medium (£2-5m), High (£10m) and Very High (£50m+) as thresholds.

U-Turn Number 1: Testing In The Community 12th March – IT cost assessment: Low (circa less than £500k sunk cost)

  • This U-Turn was a retraction towards testing in hospitals rather than testing in the community. There would have been a ‘sunk’ IT cost for the testing in the community work. This testing would have involved Public Health England implementing a field service for remote swab testing and delivery of those swabs to test centres. The IT required would have extended PHE’s time booking system and resource planning. IT changes to these systems would have had IT costs. As this was scrapped relatively early we can assume that there would have been no further licence of infrastructure costs.

U-Turn Number 2: Face Coverings – IT cost assessment: Zero

  • No IT changes as this was a policy and information change.

U-Turn Number 3: NHS visa surcharge – IT cost assessment: Medium (£2-5 million sunk cost)

  • The NHS surcharge has been around since 2015 and is paid when applying for a UK visa. There are a number of applicants who do not have to pay it. The payment method is an online transaction (or cash if from North Korea). The government U-turn means scrapping an existing process and an IT solution that is less than 5 years old. Making the assumption that any online electronic payment solution (at UK government rates) would cost at minimum £0.5m to implement added to the integration costs (£0.75m) with UK visa system and vetting services within (another £0.75m) NHS trusts it is not unreasonable to expect a £2million sunk cost. The service is still available here.

U-Turn Number 4: NHS Staff Bereavement Scheme – IT Cost Assessment: Low (£500k as predominantly configuration changes)

  • The bereavement scheme, introduced in April, initially excluded cleaners, porters and social care workers. Introducing more groups would have incurred some configuration changes to the claims process and new infrastructure costs. £100k would be a low assessment for implementing these changes.

U-Turn Number 5: MP Proxy voting – IT Cost Assessment: Zero (no actual change)

  • The government had to U-turn to allow shielding MPs to vote by proxy. The remote proxy voting system will have had an IT cost but as no IT systems were removed there is no sunk cost for this U-turn. The introduction of a secure proxy voting system will have a necessary cost.

U-Turn Number 6: Re-opening schools – IT Cost Assessment: Medium (£2-5m as schools will have scaled IT for different re-openings)

  • The school re-opening would have forced each individual school to scale its IT solutions according to the expected demand. Centralisation of IT across the UK’s 33,000 schools provides an economy of scale but there will still have been significant unnecessary overspend caused by a late U-turn.

U-Turn Number 7: National school meal vouchers – IT Cost Assessment: Medium (£2-5m for claims process and roll-out)

  • The introduction of a national school meal voucher system required an immediate build of an IT claims and spend system. It will also have required IT investment in each supplier’s ability to scale. As this was predominantly a procedural and sizing change we can assume that the IT impact would have been relative to the size of the roll-out. For this reason I’m assessing this as having a medium impact.

U-Turn Number 8: UK Contact-tracing app – IT Cost Assessment: High (£10m+ major investment on a non-usable disliked technology)

  • As of June 2020 we know that the cost of the UK tracing app was £11.8m. It is not unreasonable to expect further costs to have been spent on testing across the Isle of Wight and preparing for national rollout.

U-Turn 9: Local contact tracers – IT Cost Assessment: Very High (£50m+ with major write-off of a centralised contract tracing service)

  • The centralised contact tracing model had its own IT solutions which are now inappropriate for scaled local use. The centralised solution had scaled infrastructure and licences for 18,000 users. It would have had a communications service equivalently scaled. The local authority solutions could not have easily been separated from the national solution meaning a lot of new build and completely new infrastructure. The costs would be very high because it has to include the completely throw away nature of the national solution and the costs of multiple stand-alone local authority solutions.

U-Turn 10: A-level and GCSE results – IT Cost Assessment: Medium (£2-5m for building and implementing algorithm and significant testing costs)

  • The government was forced to act after A-level grades were downgraded through a controversial algorithm developed by the Office of Qualifications and Examinations Regulation, leading to almost 40 % of grades awarded being worse than expected by pupils, parents and teachers. This service would have had to incur a cost to model, develop and test. It would needed to have been developed in less that 3 months and to be applied across a large data set of disparate data feeds. Different algorithms, and builds, would need to have been applied for GCSEs and A-levels.

Conclusion: Total Cost Very High (Low estimate £150m+)

Change is the most expensive process in IT. Fast change is even more expensive. Waste also incurs a missed opportunity cost of what else could be done with the capital investment. It also creates a culture of inefficiency where requirements become designed to handle all possible future change rather than focusing on immediate deliverables. All of these U-turn costs were avoidable. All governments should be held to account on the waste associated with U-turn changes.

Cloud Migration of a Legacy IT Estate

There are many things to consider when migrating a legacy IT estate to the cloud. The first though must be what are the motivations and expected benefits. Many organisations have many decades of developed software running on private infrastructure and migration to the cloud is something they think they should do.

Migrating an estate to the cloud incurs a significant cost hurdle as new functions are required just to support migration activities. Often the benefit is minimal as only limited efficiencies can be found from closing (or worse partial closing) of legacy applications and data centres.

What is needed is a target systems architecture aligned to business benefits and vertical product supporting IT Stacks.

The systems architecture should reflect management of intermediary states between internal hosting and public cloud. The management of intermediary estates can easily increase an organizations run cost; for example if Corporation A decides to migrate all of its channels’ IT to a public cloud it will need to build an integration from public to private infrastructure, lease connection between new and old sites, provide a security wrap and identity mgmt function across internal and external clouds and finally support the operations for managing these new systems.

The benefits to support all of these new cloud enablement functions will be high. This does not mean it should never be done but the business must address how benefits like improved time to market will be substantively realised.

A TOGAF business architecture should be included before migrating as migration for the sake of hosting will only ever be a platform change. The balance has to be on how much change your organisation can stomach in a single move. Always consider that the SaaS services you are considering will probably be more configurable than your legacy estate. So don’t fall into the myth of business architecture as business change does not always have to be front loaded.

Securing Smart Device Communication using ETSI M2M Service Capability Layer (SCL)

Smart M2M devices require authentication & registration with the mobile network. Standardisation of service is proposed by the ETSI Service Capability Layer deployed to the Mobile Internet Device / Gateway. Security between the network and the mobile internet device requires authentication, key agreement and establishment that enable M2M Service Bootstrap, provisioning and M2M Service Connection procedures that are grounded on a clearly defined key hierarchy of the M2M Node.

The European Telecommunications Standards Institute’s M2M Release 1 provides standardised security mechanism for the reference point mobile internet device. This architecture is based upon the following principles:

  • ETSI M2M adopted a RESTful architecture style with information represented by resources structured as a tree
  • ETSI M2M standardises resource structure that resides on an M2M Service Capability Layer (SCL) where each SCL contains a resource structure where the information is kept
  • M2M Application and/or M2M Service Capability Layer exchange information by means of these resources over the defined reference points
  • ETSI M2M standardises the procedure for handling the resources

ETSI M2M Diagram

The SCL is deployed to the M2M mobile Internet device (mId) / gateway and requires authentication & registration with the M2M network. ETSI M2M provides standardised security mechanisms for the reference point mId. Mobile Internet Devices/gateways hold secret keys protecting the connection in a “secured environment” and are provisioned with the key M2M Root Key (Kmr)

This requires using RESTful operations over the mobile internet device:

  1. M2M Service Bootstrap:  provision M2M service provider assigned ID & M2M Root Key (Kmr)
  2. M2M Service Connection: mutual AuthN of mobile internet device end points & generation of M2M Connection Key (Kmc – derived from Kmr)
  3. (Optional) Mobile Internet Device security: establishment of secure communication over mobile internet device based on Kmc (and sub-keys)

More information:

ETSI M2M Security Standards 

Moving Away from a Push Model for Enterprise Identity Architecture

The discipline of Enterprise Architecture and an architecture for identity management do not currently have a best practice. The TOGAF discipline of Enterprise Architecture promotes a holistic and systemic view for interoperable systems; these may be supply chains, business processes or identity repositories. The Emerging Architecture of Identity Management argues that identity management is based on a push model with provisioning from an authoritative source as its locus. This push model exists because as enterprise systems proliferated the only viable HR approach was to provision identity to each subsequent enterprise system.

The Open Group white paper on Identity Management (W041) presents an architecture based on Delegated Authority and a master Authoritative Source. This model is firstly a push model with trust provisioned down to enterprise systems.

It is time for a review of this architecture because from an Enterprise Architecture discipline a systemic best-practice must be aware of growing trends and technology driven best practice. This author believes that authorisation needs to be contextualised and separated from joiners and leavers processing. Authorisation requires more intelligence and the proliferation of OAuth and Facebook APIs into enterprise systems (e.g. Social Authentication) will require enterprise’s to have a better approach to Attribute Based Access Control. This will provide the further benefit of not requiring enterprise’s to invest on enterprise system provisioning connectors which require regular updating and often manual intervention for everyday tasks such as promotions, demotions, joiners & leavers.