The Long Now of government IT

29 November 2006 by Rod McLaren

I’ve just been reading Baseline’s long piece on the travails of the NHS’s IT programme, a long-term IT project to render a load of patient services digital and coordinate a lot systems, organisations and people. It’s doubly long-term because it takes ages to build and will then need to run for a very long time.

Long-term projects are common in government. Recently we’ve been helping write a proposal for the IT piece of an outsourced public-sector service whose operational contract doesn’t start for about 3 years (before which there’d be a build phase of a few months), and doesn’t finish until the mid 2030s.

Don’t design 2030’s IT in 2006

It’s difficult to know what the technology requirements will be for the project in 2015 or 2030, because they’re likely to change, even within the parameters of an inch-thick contract that appears to describe a rigidly uniform service. The reality is that both customer and supplier learn as the project goes, and externalities have an impact. From the here and now in 2006, some of the future technology could look indistinguishable from magic!

There are some fairly obvious things that could go in our proposal:

• The compliance requirements require that we privilege the data and the reporting. The supplier will get paid for compliance, which is measured on the data the supplier provides to the public-sector customer. If the user performed a task correctly but the reporting doesn’t show that compliance, the user’s employer is penalised for non-compliance. So in starting – and later in changing – the system, we start with the data we want the system to output and the views of the data we want the reporting to provide. (Note for designers: this can sometimes feel at odds with user-centred approaches, but it makes sense because it provides a context for user-centred design to take place meaningfully.)
• We need to design the data to be extremely permanent if it needs to be kept over the course of the contract. This implies a focus upon resilience and archiving—additionally, the contract negotiation phase should make clear when historic data may be safely erased. We don’t yet know what kind of views we’ll need over the data when it’s a pile 17+ years deep.
• Conversely, we should design the components to be extremely replaceable. For instance, there should be sufficient abstraction that we can swap out different components and levels of the solution (eg user interface, databases, infrastructure, application architecture, and so on) as we discover new needs or better ways to do things, or when a new database or data format is mandated at some point in the future.
• On previous projects we have learned (repeatedly) the value of loose constraints. Over time, the teams of people running the service always develop solutions that work for thier local context. Which means that our solution must be flexible enough to allow users to retain and develop local solutions and customs whilst still being contractually compliant. (We wrote more on this in People over process and IT in mobile workforces.)
• Remember to plan for the IT lifecycle. The service needs maintenance, and the myriad of small improvements that are natural once a service goes live. But we’ll also run to a longer calendar as the requirements change, or we discover better ways to do things periodically. So our proposal might say something like: “It’s going to cost X to get up and running. Then Y per year maintenance and small improvements. And you may want us to rewrite some of the technology every 5 years, so call that Z every fifth year.” (In fact, we might suggest entirely decoupling the budget from the technology solution: we might agree a fixed price, and let the scope of changes and enhancements be as flexible as possible within that budget. That would allow us to make the technology/budget decisions when we know more about the changing requirements. That is, we let the budget rather than the technology be the major constraint.)
• The approach to replacability mentioned above also includes the vendor – the solution should allow our customer to get rid of us, taking their data to a new solution and vendor. In any case, there’s a need to manage this service in the long-term that can provide continuity of service.

I was in my thirties when we went live

If our proposal is successful and we’re still working on the project by the contract termination, I’ll be in my sixties. Erk.

So this starts to feel like the territory of the Long Now Foundation, an organisation which aims to promote “slower/better” thinking as a counterpoint to today’s prevalent “faster/cheaper” mind set. Their plan to create a 10,000 year clock offers some interesting principles (longevity, maintainability, transparency, evolvability, and scalability) that might be applied on this project.

That got us thinking about some less obvious things that might be needed on this project:

• Humans are first-order components of the system (as much as or more so than the technology). Expect and allow for local solutions and ritual.
• “Lifecycle” might not be a metaphor! Some of the people working on the service now will be retired before the contract completes. Some of the people who will work on it may not yet be born.
• Transparency: it should be possible to determine operational principles of the system by close inspection. Ideally the systems are somewhat self-documenting.
• Fairly easy maintenance (via KISS and transparency and self-documentation).
• Flexibility: It should be possible to improve the system with time. There’s obviously the risk improvements affects the system’s longevity and simplicity though, but we’re pretty confident that we don’t have all the answers in 2006.
• design the IT and the processes and organisation wrapped around it for stability and longevity. (Matt suggested that it’s not really a project – it’s the establishment of an institution. The institution has a task, and the software is the current implementation of the task. It’s like running a university college, he said.)

Which left us us with some interesting questions: How do we design tasks and institutions for both longevity and adaptability? How should the people passing through the institutions behave? ... and we’re still thinking about them.

Design principles for public sector and enterprise mobile applications IT, operations and politics in The Wire