One weird trick that the law uses to specify state computer systems
This is a response to Stefan Czerniawski’s article on Law, Code and Systems which in turn was a response to my blog post on technology and the public sector.
Lets start at the beginning.
There is a causal relationship between legislation and computer systems — a law is passed to regulate, administer or deliver something and as if by magic a computer system or systems springs to life — its like sowing dragons’ teeth.
So the question is how does that happen? What is the relationship?
Lets step away from law and look at how computer systems are specified, in particular the cline of pedantry:
So at the left hand side we have a very protean thing — goals and objectives — these are simple to rewrite, have many equivalent or nearly equivalent versions. As we move along the process each stage becomes more and more fragile. The executables themselves are a series of 1’s and 0’s — and the transposition of a single pair of them can prevent the system for working at all.
The software development process is about deepening and fixing a specification, then a technical (or functional) design and then building up working code.
The goals and objectives are effectively free narratives which are then constrained into structured business objectives, nailed down in more rigid technical objectives, etc, etc.
It turns out this has a family resemblance to law making— which also has a cline of pedantry:
My argument is that these two processes are (at least partially) co-mingled in administrative legislation:
Legislation is not a form of code — but a form of computer system specification. Law says how judges should make decisions, computer specs say how computers should make decisions.
It seems to me that a bill that leads to the implementation of a computer system has essentially three different sets of components:
- clauses that specify the business specifications — what the system should do, how it will work (Act I in the diagram)
- clauses that specify the data and how it should be managed (Act II in the diagram)
- clauses that do not pertain to the computer system — establishment of an organisation, pay and conditions for staff, funding, audit, etc, etc (Act III in the diagram)
These three distinctions are important for a number of reasons.
When I was the technical architect on Edinburgh City Council (as part of the BT contract) I did a straw poll around my support teams and we counted just north of 80 sets of person data — data about people. These could not be consolidated in a single database because the data management options were simply too complex. The retention time of social work data is 99 years plus survivor’s lifetime, that for council tax will be something else, etc, etc.
At the moment these separate roles of legislation are implicit — simply by reading the legislation you often don’t know what role a clause is playing the specification of the new computer system — sometimes it is doing two things, often it is doing its job badly.
Only by making these distinctions explicit can we design new and improved processes — which is prerequisite for designing world class computer systems.
Data is how systems are co-mingled and interoperate — and extracting and simplifying data legislation would improve system interoperability.
There are essentially 8 things that pertain to how legislation specifies data:
Definition
The specification should include a single point of definition of the data. This might be:
- a piece of legislation
- a person authorised to issue the data definition by way of tabled regulation — eg secondary legislation
Audit
This should consist of a statement about the person or body authorised to audit, review and generally oversee the use of the data, including:
- data maintenance activities
- release of data to external bodies
- review, routine deletion and weeding of data
- all aspects of compliance, including with: the Human Rights Act, Data Protection Acts, Freedom Of Information Acts, etc, etc
Recourse
This should document:
- the person or body authorised to handle disputes as to the existence or not of a data record — I am not on the list, I should be/I am on the list, I should not be
- any due processes required to do so equitably
Partition
This should document:
- how the data is partitioned between different organisations (eg local councils, or health boards)
- what activities should be taken to manage data across partition boundaries
Now we get to the more familiar data operations.
Create/Read/Update/Delete
These should state who, why, when and how the data should be created, read, updated and deleted.
In addition, there may be additional statements on the provision of read-only access to data covering topics like:
- the provision of external searchable feeds for use by other state agencies
- mandatory indexing
- and so on and so forth
There is also a requirement to define what the data will be read for, in particular with relationship to its use in management information or intelligence systems or as the basis for reporting.
You will see from the intertwingling diagram that I don’t think legislation is ‘code’ — and I don’t think code is justiciable — I believe that code can be found not to conform to the business and data specifications defined in law — but it isn’t justiciable itself.
If you think the process is complex as I show it now, consider how messed up its looks when you show how people actually develop software these days — iteratively:
What I would like to see is appropriate sections of administrative legislation subject to an iterative legislative process:
Notice that there are different audit regimes for different aspects of the Bill. In the Scottish Parly the bill pack already contains a Report on the financials to assert that they have appropriate quality before the legislators vote on them.
There is no reason that other audit regimes that are commonly used in commercial software should not be applied to state software: usability, performance, data design quality and so on.
The new process that the Minister Jeane Freeman has put in place for the Scottish Social Security bill starts looking somewhat like this:
This iterative approach with sign-off delayed on proof of success would have stopped some of the most egregious software disasters: from the NHS Spine, through the Scottish EU Agricultural Payments disasters and the Universal Credit fiasco.
NHS Spine was finally killed in 2011, but we technical architects in BT knew it was dead in the water as early as 2004. There was no process to stop it.
BT lost £2bn, the Government lost, what £11bn? £12bn? do we even know?
We know from 50 years of IT systems that its a case of Cheap, Fast, Good, pick 2.
Lets pick Cheap and Good.
If you like this article please share on social media.
