We Built This

We spend a lot of time talking about legacy technology, monolithic systems and vendor lock-in as though they happened to us, as though suppliers arrived with enormous applications and somehow trapped otherwise innocent public services inside them, when the reality is both less convenient and much more human than that. We built this, or our predecessors did, and if we had been sitting in their chairs with the same technology, the same organisational pressures and the same need to move entire services away from paper, most of us would have made exactly the same decisions.

It is easy to forget how much of government once ran through filing cabinets, forms, folders, photocopies, post rooms and the accumulated knowledge held in the heads and desk drawers of experienced people. Getting work off paper was never going to be achieved by dropping a system into an organisation and expecting everybody to use it, because paper was not simply a recording medium, it was woven through how people understood their jobs, how work moved, how decisions were made and how responsibility passed from one person to another. The only credible way to change that was through co-design, bringing together the people who did the work, the processes through which the work happened and the technology that might enable it, then redesigning all three together.

People, process and technology became the standard precisely because technology adoption was a human and organisational challenge before it was a technical one. We sat alongside the people delivering services, mapped what actually happened rather than what the procedure said should happen, worked through exceptions and professional judgements, and translated years of practice into workflows, screens, permissions, records and rules. The people doing the work needed to recognise themselves in the new system and trust that it would support them, while the system needed their knowledge to become useful, so the operating model and the technology evolved together until they became symbiotic.

Housing officers learned to work through housing systems, planners through planning systems, social workers through social care systems and revenues teams through revenues systems, but the relationship worked in both directions because those systems had been shaped around the language, practices, responsibilities and decisions of those professions. We did not simply digitise the paper form, although sometimes we did that too, we took the knowledge that had previously lived in people, teams and physical processes and embedded it into technology, creating consistency, visibility and control while allowing organisations to operate at a scale that paper could no longer support.

That was not failure.

It was successful transformation for its time, achieved by involving people in the design of technology that would become part of their working lives, and it is important that we do not rewrite that history simply because we now find ourselves living with some of its consequences.

The technology available at the time made the application the natural centre of this new operating model. Systems were hosted on premises, infrastructure belonged to the organisation, and local administration teams understood their applications in remarkable depth, often knowing not only how to configure them but why a particular field, workflow or integration existed in the first place. They managed upgrades, permissions, reports, interfaces and the endless local adjustments needed to keep technology aligned with services as legislation, policy and practice changed, while local infrastructure teams ran the servers, storage and networks beneath it all. Connectivity between organisations was limited, integration was difficult and expensive, and data naturally remained inside the application and the organisation that owned it.

In that world, buying a comprehensive system was not poor architecture, it was risk management. If the organisation was responsible for the whole service, and if the people, process, data and technology had been designed as a single operating model, it made sense to procure a product capable of holding the whole thing together. It also made sense to specify every requirement, preserve important local variations and ask suppliers to customise their products, because changing the technology meant changing how people worked and nobody wanted to lose the hard-won knowledge that had made the service function in the first place.

Procurement practice grew from those conditions. We asked people what they needed, converted their needs into detailed requirements and went to the market looking for a system capable of meeting them, with each organisation repeating that process because each was accountable for its own services, infrastructure, information and outcomes. Suppliers responded rationally by building larger products, absorbing more capability and accommodating more local variation, while organisations became increasingly dependent on systems containing not only their data but substantial parts of their operating model and organisational memory.

That is how thousands of organisations solving similar problems created thousands of variations of broadly similar technology, and how suppliers became deeply embedded, not because one side set out to create lock-in but because the system, the data, the business process, the professional practice and the local knowledge became progressively harder to separate. The more successfully we embedded technology into the work, the more consequential replacing it became, and the larger those products grew as we kept asking them to absorb another process, another requirement and another locally designed variation.

The whole system reinforced this direction. Organisations were funded, governed and held accountable individually, procurement sought clarity about who owned the risk, and technology architecture mirrored institutional architecture because both were designed around the same organisational boundaries. Councils bought council systems, departments bought departmental systems and health bodies bought health systems, not because people were unable to imagine collaboration, but because responsibility, budgets, data, infrastructure, decision-making and scrutiny all sat within the institution. The safest technology choice was usually the one giving the organisation the greatest control over its own part of the world, even when the accumulated effect across the public sector was duplication, fragmentation and dependency.

What we now describe as legacy is therefore not simply old technology, and vendor lock-in is not just something suppliers did to the public sector. Both are the accumulated result of decades of co-design, local ownership, institutional accountability and sensible attempts to make services work better within the constraints of the technology and the wider system available at the time.

We built systems around organisations because organisations owned the infrastructure, employed the people, held the accountability and delivered the services. We made people and their work symbiotic with technology because that was how we moved whole professions from paper into a digital world, and we made applications larger and more comprehensive because the rest of the system rewarded organisations for controlling their own end-to-end delivery.

The problem is not that we made those choices.

The problem is that we are still repeating them after the conditions that made them necessary have changed.