I posted online recently some headline stats comparing the relative scale of UK banking transaction volumes with UK government transaction volumes. They sparked a healthy debate about the nature of ‘transactions’ and the complexity of processing required of a transaction embedding a complex welfare claim form relative to one for a simple financial exchange.
Neither the estimate of total UK banking transactions per annum nor the estimated number of UK government transactions seem reliable in my original post (one commentator suggesting that for just one of the government services the true figure was of a magnitude 7x greater than that shown on the Govt Transactions Explorer). Also, some is inevitably double-counting: something may start as an HMRC payment and then become a banking transaction, so there’s a degree of mutual inter-dependence in such figures.
After much internal debate, I decided to pull that original infographic — to prevent the propagation of something potentially misleading without a proper context. Irritatingly, LinkedIn removed all the subsequent comments too — if I’d know that, I’d have left it there. Mea culpa and many apologies to those who contributed: luckily I was keeping a summary of the comments since they raised many useful points which I wanted to capture, so they are not entirely lost.
So, important lesson learned … and to return to my original point, which was about the relative scale of government IT compared to what is happening in other areas, comparative stats like these in my replacement graphic make a point about scale whilst still skirting the issue of comparative transactional complexity:
Or on the sheer scale of what the overall internet is now handling (or, at least, was handling in 2012…):
Usefully, within the 1.15bn HMRC transactions of the first graphic above, the Transactions Explorer lets us drill down to see what ‘transactions’ make up this total. And to drill down again into each specific service. It’s a very useful tool — we need to see much more of this transparency and insight. Letting the sunshine in should also help resolve issues of associated data quality — addressing the points raised that some of the data appears to be underestimating what actually currently happens.
My original point was not intended to be specifically about the nature of transactions (which after all range through the gamut of ISO 20022 domains of Payments, Securities, Trade services, Cards and FX to the GovTalk Envelope [PDF] ), but about the scale of government IT in the digital era. Implicit was also a much bigger question about whether, with a proper data architecture and redesigned public services, many of these transactions are even necessary — combined with the question of how best we architect it all (an issue usefully discussed in this blog post by Stefan Czerniawski).
Many current government ‘transactions’ are merely automated versions from the old paper world, moving electronic versions of forms from one place to another — either literally, or by mimicking the form online in a series of interminable web pages that ape the paper world. We can throw all the tin and software we like at these ‘digital forms’, but it’s not going to do much to improve the quality, efficiency, or relevance of the services involved.
The more challenging issue is how we ensure these processes and services (and indeed the organisations behind them) are re-thought and redesigned for the digital age. In the same way that distributing a text document to multiple contributors and then trying to reconcile all their comments and changes (now scattered across multiple forked copies of the original document) is being superseded by a model where documents are collaborated on online in a single place and not sent around at all, there is enormous scope for a smarter data architecture. One that moves away from mirroring the capture or flow of online equivalents of paper documents to one oriented around data and capturing the delta for specific services — such as welfare or tax — rather than the entire data set time after time for each service and functional business silo.
So yes — to start with ‘transactions’ or technology being used to automate what is there is to start in entirely the wrong place. Many ‘government transactions’ (and potentially some government organisations and agencies) could potentially be dramatically improved, or perhaps even obsoleted entirely, with better designed public services. As I’ve commented on before, the poor design of many public service processes and associated paper forms are as socially unacceptable as the same poorly-designed services delivered on to a screen. So some of the more complex ‘transactions’ that people commented upon — such as case management work — raise the wider question about the overall design of public services, and why such things are being sent around in the first place, effectively using technology to fossilise the way things were done in the paper age.
I started from the perspective that whilst once governments were often amongst the users of ‘big’ technology (in terms of scale and speed), others now have claimed that crown. More importantly, that government could learn from the best of what has happened elsewhere — and use technology as a lever to redesign our public services, not merely to automate them in their current state. That’s part of the narrative I was discussing in my recent CIO piece ‘The birth of the composable enterprise‘.
Improving our public services requires the re-evaluation, redesign and re-engineering of its organisations on every level – people, process, technology and governance. This was implicit in the comment on the LinkedIn (RIP — grrrr, lesson learned) thread: ‘Maybe the question is how many should the UK Govt be doing and not looking at what they are doing’. Those who commented that the debate about ‘transactions’ is ‘one dimensional’ and missing more important wider issues are entirely right: it’s time we had that wider and much more difficult debate — something Mark Thompson for example raises in his ComputerWeekly piece ‘Where is the long-term political vision for digital public services?‘.