Digital

Basic Law-Making For Legislative Computer Systems – Part 4

September 25, 2023 by Stewart Hamilton No Comments | Category Digital Scotland, Research

Blog by Scottish Government, Research Fellow, Gordon Guthrie. 

Gordon is a Research Fellow at the Scottish Government under the First Minister’s Digital Fellowship Programme. All opinions in this blog are his own and they do not represent Scottish Government policy.

This is the fourth of five articles outlining the research of the Blus project – Basic Law-Making For Legislative Computer Systems. Read the first here – it outlines the problems of connecting slow legislative iteration to fast digital development processes and the second here – it is about building a Frankenstein Bill that shows how legislation can accidentally or deliberately slow down development. The third looks at pattern books that describe what decisions various technical teams need to make, and what needs to be decided before they can make, and how their work is subject to scrutiny.

Part 4 – A Legislative Architecture 

This is the decision making process in government now: 

Notes: 

• Programme For Government is a Scottish government term – it means what we are going to do between now and the next election 
• Regulations is used here in the widest possible sense – as a record of decisions. They may impose conditions on citizens (bring 2 forms of identity to do this) or they may bind civil servants only (set up a programme board, produce a budget) 

We have the 4 types of decisions: at elections, in acts of parliament, by ministerial order (approved by parliament) and day to day work. 

 So what will it look like after the Blus process? Well it will look exactly the same. Bills will be bills, orders, orders and regs, regs. The difference is that the process will be explicit and not implicit. Each element will be annotated with the decisions it takes and what other actions depend on it. 

 In this example Bill 1 might decide the following thing which the data specialists need to know: 

• the system will reuse this data store 
• it will expose these elements via an API for use by other systems 

• these people will have these rights to access the data 

And these annotations will flow down into orders and regulations. 

And this explicitness raises a lot of questions. What changes do we need to make to our organisation – how we align to the various decision making levels? Is our financing appropriate? If we are iteratively developing systems we need to have iterative business and finance models. 

At this point we will also have the speedbumps documented in the Frankenstein Bill – and we can point to things in the past that have caused programmes to become unstuck and blocked, and how other people have solved these issues. 

This legislative architecture needs to join the other architectures that we maintain and map to them – the business process architecture, the technical architecture, the data architecture, registers of services and APIs and all the other components of complexity which are the stuff of the modern world. 

The key part of this phase is to lean in to complexity – not to run from it. We need to have the detail, the raw mass of complexity and we need to tame it by boxing it – you subsume this, she subsumes that, they consume these so that we can organise ourselves for complexity. 

In Part 5 I will look at how we can test this proposition. 

Gordon Guthrie is a Research Fellow at the Scottish Government under the First Minister’s Digital Fellowship Programme. You can follow his work in more detail and get invitations to participate in the research on his SubStack.

Tags: Basic Lawmaking For Statutory Services, digital, Digital services, Law and Government, Systems

Comments