Sometime late last year I went to the Euro IA conference with Anya and Silver to give a talk on the domain modelling work we've been doing in UK Parliament. Or at least they talked and I was too shy. This post is based on that, some thoughts we've had since, and walks and talks I've had with Anya, Silver and Robert.
The talk started out by giving some context around what Parliament is and how it works. Pretty much every time we talk to anyone outside Parliament about Parliament, the first point we make is Parliament is not government. A key purpose of Parliament is to scrutinise the work of government. Lots of people who you'd imagine would know better, don't really seem to get this distinction. I've had people from GDS asking why Parliament is building its own website and isn't turning to GDS like 'other government departments'. To which the only answer is, we're not a government department. And we had a civil war about this.
The second point we make is that there are various conceptions of Parliament. There's the House of Commons and the House of Lords and they happen to share a rather distinctive building. But as institutions they're quite separate. There's also the Crown, but we don't go there.
The third point grows out of that. Each House has a number of offices. Within each House, individual offices tend to mirror each other in terms of naming and functions. But the way they do what they do is often quite different. There's an evolutionary aspect to this, as ways of working might have started from a similar place but have evolved separately. Given the history of the place, there's plenty of scope for evolutionary diversity. Similar processes poke through in the language of each House. Different things sometimes have the same or similar labels. Different words are sometimes used to describe very similar things. Asking a clerk in the Commons about a comparable procedure in the Lords, or vice versa, is not unlike asking a cat person about dogs. Which is not due to a lack of curiosity. Separation of functions exist. Because constitutional separation exists.
On top of the standard organisational complexity, there's an established practice of parliamentary sovereignty that no Parliament can bind a future Parliament. In essence this means Parliament can't pass a law that a future Parliament can't revoke. Parliament doesn't run to a ruleset that's predictably consistent over time. If Parliament decides to do something in a different way tomorrow, the thing will be done differently tomorrow.
There's something a bit like pace layering here, whereby Parliament operates in different ways across different layers. Somewhere in the middle there's a recorded ruleset comprised of legislation and Standing Orders. Legislation determines, for example, that a certain committee must be established. And Standing Orders determine likewise for other committees. Obviously, Parliament has no standing orders. The House of Commons has one book; the House of Lords has a thinner tome. In fact, they each have two sets, but that's beside the point. And all of this is subject to change whenever Parliament determines it should change.
An additional layer is precedent. How things have happened in the past informs and describes at least some of the possibility space of how things might happen in the future. If you spend any amount of time with a clerk discussing procedure, and ask them what happens next, they may say, it goes to this committee. And what happens next? It goes to here. Or it can go to here. At which point a colleague will chip in to say that it hasn't gone there since 1957, and a polite argument will break out. Lots of Parliament runs like this. It's more a collection of overlapping narratives than a process map. Erskine May operates at this narrative level, providing a repository for stories of how things were done in the past. Which in turn provide a starting point for how things might happen in the future. Given Erskine May is a bound volume and precedent is always subject to change, it can never provide a complete picture. New 'stories' are born and usually go to live on the S drive. Until they're included (or skipped over) for the next volume.
The third layer is, unsurprisingly, politics. Or people if you will. Again if you speak to a clerk about process, at some stage they'll almost certainly say, 'then it goes to the usual channels'. From a parliamentary point of view, everything disappears off stage. The party whips and business managers get together and do whatever party whips and business managers do. Having concluded negotiations and come to some decisions, the whole thing moves back on stage and process and precedent take over.
So what? The lack of a fixed, exhaustive ruleset means Parliament is open to exaptation and adaptation. It is evolutionary by design. It is not brittle. It can sway in winds. Computers on the other hand are really not like this. They tend to prefer defined rulesets. They are deterministic. They are dumb. They are brittle.
Building software, and designing the data models software relies on, to even approximate Parliament is hard. It's made all the harder because computers are deterministic beasts and Parliament is not. There are large chunks that just don't lend themselves to computers. Taken to an extreme, you might say the determinism of computers and computer people is antithetical to how Parliament operates.
One approach is to ignore it all, and consider the offices across the Houses individually autonomous (which they largely are), and digitise the individual processes that happen in each. And hope that those processes don't evolve faster than the software. Which, unfortunately, they probably will. Building software around an office, in a House, buys you out of a lot of problems. You can take the approach of throwing the resulting documents over walls, between offices, between Houses, as it reflects a current reality. If you do take this approach, you can leave change management to the individual offices. Make every lookup list configurable by the people who work there. If a new kind of committee comes into being, they can add it to the list and everything's good. At least until you try to combine all this stuff into a higher level, or more integrated, view of how Parliament works.
This is how data.parliament came into being. All the data from all the applications was thrown into a triple store, seemingly along with an expectation that somehow it would all magically reconcile and interconnect. data.parliament runs on a triple store, but no-one designed a data model (or ontology, if you will) for it. Silver and I spent some time attempting to reverse engineer a data model out of the data we found. We came up with this picture. If you squint hard enough you can see the shapes of individual offices in Parliament. The division data is connected to the people doing the dividing, but not to the motion or motion amendment or bill amendment the division was on.
Given that the current website relies on many of the same data sources, many journeys across the website are also disjointed. We have almost as many subdomains of parliament.uk as we have offices. Partially cobbled together with a CMS, but without meaningful links between different aspects of the same thing. A fairly fundamental rule of information architecture is to not expose your internal organisational structure to the outside world. The data silos we have mean we haven't been able to do anything else.
The problem is that most parliamentary processes touch multiple offices across both Houses. The passage of a Bill will involve the Public Bill Office, the Table Office, the Committee Office and the Journal Office. All of that (usually) across both Houses. For anyone outside the offices, including Members of Parliament and their staff, building a picture of what's happening is hard. Harder than it should be. We have all the complexities of parliamentary business overlaid with a interface that's complicated in a completely different way. Even for someone who knows how Parliament works, it's tough to see what's happened, what will happen and what might happen next.
In some attempt to help solve this, we're working with clerks to understand their processes and the flow of information between Houses and offices. To the extent we pretend to understand Domain Driven Design, we use those techniques to sketch what they tell us and get them to sketch back our mistakes at us. To the extent we pretend to understand Cynefin, we also use that to break apart the obvious / complicated (procedure), the complicated / complex (precedence) and the complex / chaotic (people and Politics). All with a firm understanding that much of what goes on in the place we call Parliament cannot be forced into a model that computers can understand. Though other people's mileage may vary here...
Just occasionally, usually during fag breaks, we have a vague existential fear that we're pinning down definitions that haven't been pinned down before. And that trying to pin things down can lead to a lack of flexibility that, at some point, might make the software we make brittle. And break. Occasionally it feels like trying to render poetry as equations. It's always going to be lossy but what gets lost?
A trivial example from a few months back. We were working on a model to describe parliamentary time: Parliaments, Dissolutions, Sessions, Sitting Days etc. Two questions came up that seemed related: when does a Parliament start, and when does a Member of the House of Commons become a Member of the House of Commons? We knew Parliament dissolves before a general election and at that point Parliament ceases to exist. The date for this happening is easy to identify, being set by either the Fixed-term Parliaments Act 2011 or declared in a royal proclamation issued after Parliament has voted for an early general election. And prior to the Act, by the Dissolution Proclamation. When a new Parliament starts we were less clear on. An email chain went round several of the senior clerks who decided the correct answer was on the day named "in the Proclamation declaring a new Parliament, which since the passing of the Fixed-term Parliaments Act is made on the day after a statutory dissolution (prior to that the Proclamation dissolving a Parliament also named the day for the new one to meet). That correlates with the day on which the Speaker is elected (or at least the first attempt to elect him or her is made - if it were opposed the election would happen on the next day)."
You definitely cannot have sitting days outside a Parliament so the answers which suggest you can are wrong. The Parliamentary Oaths Act assumes that the oath is taken “in” every Parliament (i.e. the Parliament exists by the time the Members swear the oath). While it would be unwise to put too much weight on a single word in an 1860s Act, but it's an indicator that the Parliament begins on the day named in the proclamation.
The second question proved more difficult to answer. The same set of clerks did come to a decision, though not quite a unanimous one:
The Recall of MPs Act 2015 states at 2(5) that
For the purposes of this Act the time at which a person becomes an MP is the beginning of the day after—
(a) the polling day for the parliamentary election at which the person is elected as an MP, or
(b) where the person has been elected as an MP more than once, the polling day for the parliamentary election at which the person was last so elected.
From a computer pedant's point of view this is odd. A Member of Parliament becomes a Member of Parliament at a point when Parliament is yet to convene, so technically, there's nothing to be a member of. In some ideal world you'd want each time period to be wholly contained by its surrounding time period. But this isn't how things work.
There's something slightly sad about defining these things in quite so deterministic a way, Parliament has functioned perfectly well without pinning these definitions down. It's a fairly minor example, but still we worry a little that we're taking a system that's open and adaptive and evolutionary, and trying to make it more amenable to computers. Which aren't any of those things.
On a slightly deeper level, we've recently been looking at parliamentary procedure and how we might track the journey of Statutory Instruments (SIs) through Parliament. We've documented flowcharts for each of the related procedures, which must be at least the hundredth time someone has drawn an SI flowchart. Although we like to think ours are better. Or at least more comprehensive.
We've also designed an abstract model for parliamentary procedure. Which, in truth, is not a procedure model but a lightweight process model. It started life with some work me and Silver did at the BBC around the time of the 2010 World Cup and a need to model what matches might take place, given results and possible results of other matches. Anyway...
For the first time, we have a model of parliamentary procedure that machines cannot only read but draw inferences from. Given enough instance data, we can start to query common routes through procedure, successful points of intervention and less successful points of intervention. We think it's interesting and at least something akin to what elders and betters might call digital transformation. Or whatever the new buzzword is. But again, we wonder if attempting to model complex human interactions and occasionally disputed narratives is at odds with how Parliament works.
In all of this, I'm reminded of a recent Twitter spat about the possibility or desirability of legislation as code. The idea you can take law and make it not only machine findable but also machine legible and machine interpretable. My argument is you can't and, even if you could, you really shouldn't. Legislation should be loose enough to be open to interpretation. By people. Not machines. And the same feels true of Parliamentary procedure. Or any complex, adaptive system.
Which is not to say we're arrogant enough to believe that turning up with post-its and Macbooks and turning complexity into some bits and bytes will make Parliament stop working. Or even make it brittle. Parliament, we're sure, will sail on regardless. As it always has. And we insulate the model against change by making procedural steps, and routes through those steps, and even whole procedures, time bound. But there's still a worry that plonking the determinism of computers over the improvisation and adaptability of Parliament somehow diminishes what Parliament is.