About the CV19 contact tracing breach

The UK’s world class “Track & Trace” application “lost” 16,000 cases for over a week, as reported in many places, but here is the Register. Plenty of people have decided to comment and so I thought I’d join in. Much has been made of the fact that the “dashboard” seems to have been implemented in an old version of Excel which has significant element array limitations and as pointed out to me by the Register, significant calculation errors which may lead to error program logic processing. This article talks a bit about why such decisions might be made and also how to perform good architectural practice and good program deployment and thus what might have been missing. It’s unlikely that such a mistake won’t be repeated, the people at the top, have not been through the painful process of failing in this way and paid a price.

Rachel Coldicutt in her medium post, “Magical thinking and maintenance” argues that developers and managers just want to make new shiny things and that even essential maintenance, including product upgrades are postponed. Some of the most infamous system failures including the Ebay outage, the Nat West 3 day retail bank outage and the wannacry crisis have all caused by failure to manage software infrastructure version control. We should remember that it is an axiom of good IT security that users must have a support escalation route for third party software, and that this must include access to source code engineering support. The shiny toy syndrome in government is well illustrated by the renaming of CCTA, it’s movement to the Cabinet Office and the fact its most famous programme was borrowing Google’s office furniture schemes with comfy chairs and free coffee. Coldicutt’s article is a plea to prioritise maintenance programs, which loses out because the perceived ROI is always low and so few people have heard of the fact that ROI is a poor indicator of the worth of IT projects and that now that computer power is a current account spend, funding capital[1] is no longer as important as it was. Maintenance and product upgrades are critically important. 

This tendency to prefer the shiny, new and a blank piece of paper also means that unless the author/user is frightened of the regulators, they concentrate on code and not on governance.

Any organisation of size needs an IT architecture plan. This maximises the opportunity for systems interoperability, compliance measurement within the supply chain, future scalability and cost control of both acquisition and support.

Most architectural plans will include a spreadsheet as a desktop/user tool. At times, Excel has been the most popular development tool and for many sites is the most pervasive applications platform. Skills acquisition in using it is easy to acquire, and Microsoft offer accreditation schemes to allow management to know that the people they employ can use it properly. Reasons for worry, are expressed in their usual robust style, in this article, “Excel Hell: It's not just blame for pandemic pandemonium being spread between the sheets”, from the Register, who also argue that Excel has no role in regulatory compliance software. These plans need exception approval processes, and a means of including user authored programs.

On the question of the architectural appropriateness of a spreadsheet, when helping one of my sons do some early homework, we developed the following definition of a spreadsheet,

A spreadsheet is a program designed to report on and analyse data best represented as tables.

We were concerned about verbal economy and this definition also allowed us to answer the question as to what one would use them for, with little change. The problem is that relational databases are also programs best used for analysing and reporting on data best represented as tables but we need to recognise that spreadsheets are terrible at dealing with many-to-many relationships, graph relationships, geographical operators and hierarchical semantics and lists.

The final piece of the jigsaw is the software development life cycle. A lot of effort has gone into understanding how to do this well with much written about requirements management of functional and non-functional qualities, testing of functional and non-functional qualities and release management. The processes of vendor and vulnerability management are also important parts of ensuring software does what’s needed safely.

[1] Unless it is. You need to be able to prioritise between information systems and industrial plant.