It was a mistake to have breakfast with William Heath.
In his charming way, he took one of my long-held ideas, held it up to the light, and found it wanting. Worse still – and equally characteristically – the challenge was as powerful as it was simple.
I have argued for some time that there is an important difference between front end and back end systems, with the two approaches and cultures most apparent at a seminar a couple of years ago. As I said then,
We need to apply two different sets of disciplines (in both senses), in two separate domains:
- An approach to the customer experience – both offline and online elements – which is flexible and responsive and which maximises its exposure to customer intelligence in order to do that
- An approach to the supporting processes which is robust, consistent and correctly applies the full set of rules
Despite that, I am in no doubt that the balance needs to shift from a back endian to a front endian view.
I am absolutely sure that the heavy engineering approach cannot deliver agile customer focus. I strongly doubt that the pure version of customer driven permanent betas will deliver the back end resilience which remains a real requirement – though Dominic Campbell has a neat encapsulation of the alternative, Steinbergian, view. Tom makes a virtue of not caring how local authorities pick up and deal with the information which FixMyStreet passes to them. But the real value to the citizen is not the reporting but the resolution – so local authorities have no choice but to care how they efficiently translate reports of problems into activity planning and into the activity itself. And I doubt that anybody is going to claim to have built one of those with change from ten grand.
William’s challenge, in effect, is whether we have now got to the point where that distinction is no longer important. To run the tax or welfare systems, you need big databases which process complicated rules and changes, with thousands of concurrent users, strong resilience and robust security – or in other words, some pretty serious systems engineering.
But to run Facebook you need big databases, with millions of concurrent users, managing records which are both massively more complex than anything government has and massively more interdependent. The numbers are jawdropping: 300 million active users, 45 million status updates a day, to say nothing of the 14 million videos and 2 billion photographs uploaded each month. There are still some important differences, of course: there are good reasons for the security model to be very different for a government transaction processing site than for a social networking site, for example, but it is now a lot harder to argue that the traditional database driven government backends are inherently more big and complicated than the much more flexible and light-footed web 2.0 services.
So what’s stopping government, William asks, from switching to the facebook model, and facebook cost base?
A fine question to be confronted with before the first cup of coffee has fully kicked in.