Dave Winer is talking up one of the key virtues of RSS – that it’s an open API and can be implemented in an afternoon. Anyone, he says, who does an API however they please would be bonkers, unless they were a large org with a purely internal need.
When we built the Government Gateway (the one that Kablenet notes may now get some local government usage but that is already being used in a couple of places elsewhere on the globe), one of the absolutely fundamental reasons for doing it centrally was that we wanted a single API for authenticated transactions coming into government. We didn’t want a Sage or a Rutherford-Webb or an Egg or anyone else having to figure out multiple ways in or different dialects. In short we wanted an open API that anyone could use. It’s been an interesting journey getting there – hard for digital certificates, much easier for userid/password – but there’s now a lot of vendor community support, both at a system integrator and an application provider level. The first real fruits of that will come in the first quarter next year I hope.
The reason that we thought it was important, even back in mid-2000 when we were designing it, was that we knew this curve existed:
i.e. government is relatively low on the interaction frequency curve and needs to move up, through the use of intermediaries, before online government would become truly effective. The reason people bank online is that the efficiency save is great – 3-4 transactions a week can save you a couple of hours of standing in a line. 1 transaction a year with government might as well be on paper – people don’t yet get the efficiency potential (and who can blame them?). I didn’t put this curve up in slides until November 2001 (by which time the Gateway was long since built and was a viable route into government, maybe even the only viable route).
A couple of months after first posting the curve, I added this slide to my deck to go with it:
The point being that many transactions plus good information to navigate you around them PLUS multiple ways in through third parties (whether web or application) would drive takeup. There was not going to be a single thing that drove traffic to the government’s online presence (although it’s possible now that tax credits came very close and may do so again next year).
Today, there’s still a frightening amount of debate about whether this makes sense – both opening up to intermediaries and having an open API. Policies on a mixed economy ought to have laid the former argument to rest, but if the latter one isn’t won too, then it doesn’t matter much. Folks who want to develop synchronous inhouse communications between their portals and their backends fail to see the closed loop that puts them into – they fail to see that only through putting services online and joining them up, the way the customer sees them, will we make breakthroughs. Delivering silo services may be pretty for now – in fact, it would have been pretty in 2001 now it just looks dated and closed minded – but it won’t get the kind of takeup needed.
There are, as always, some exceptions to this – it’s unlikely that someone will want to book a driving test and claim benefit at the same time, but it is very likely that someone will want to determine their eligibility for a variety of benefits and tax credits in a single go. Doing anything that prevents this latter service may forever delay joining up government services because, as we have now (everywhere in the world), the output is a monolithic, legacy piece of IT built for the sake of IT and not for the sake of customer. Time to stop spending all the money on the “T” in IT and spending it on the “C” in Customer.
