osrin.net

Almost ten years ago I was involved in the process to write one of the first eGovernment Interoperability Frameworks, the eGIF work in the UK.

At the time we had some big interoperability decisions to make, ones that were fundamental to the issue of connecting basic infrastructure. In the government at that time there were no definitive decisions about how some of the basics might work, would we connect systems together using TCP/IP, OSI TP0/TP4 or SNA? would we move email around using the incumbent X400 protocol or adopt the emerging SMTP standard?

Version one of the UK eGIF really helped departments at all levels in government think through these fundamental issues.

Today those same issues look a little brainless, the wider market has made its decision and we all know and the protocols that run the internet provide the same basic answers to government, citizens and enterprises.

The EU, with the first version of the European Interoperability Framework, took this thinking one step further and introduced the concepts of multiple challenges within government to solve the interoperability challenge. The document extended the Interop domain challenge to look at organizational challenges and semantic language challenges faced by departments who are working to connect services together, while keeping the technical guidance that countries like the UK had worked on as a third tier of activity.

Today many countries around the world have adopted this same approach, at the very least documenting lists of technical standards that can be adopted across government and in many cases adopting the same three tiers of interoperability policy activity that the EU project originally defined.

When I look at many of these documents today the technical chapters have evolved hand in hand with the way that the market has evolved, but stepping back they’re starting to look a little odd – at least to me.

Many of the basic technical challenges have been solved by the industry and adoption of those standards has been driven by consumers and businesses. To me it no longer seems necessary for governments to spend time maintaining a document that pushes departments to select TCP/IP for networking, or HTTP/HTML support in web based applications and browsers. These things are still important, but it is probably time to take a step back and think through what is really inhibiting the delivery of joined up services in governments today.

While there is still a high level of focus by governments on the technical aspects of interoperability, there only appears to be a limited increase of activity on the other two complex challenges that we collectively face.

For any country looking at solving interoperability challenges at a national level today I would suggest a very different approach to the one we took in the UK a decade ago.

In many cases (certainly not all cases) the technology will support the levels of interoperability needed to connect systems together, but it can still be very challenging to get departments to work together and answer the core organizational questions that need to be answered before they can deliver a seamless business process. Assuming that the organizational challenges do get solved, then the semantic language issue is equally in need of rigorous academic work and policy focus.

Interoperability, on the level needed to deliver eGovernment connected services, isn’t a technical challenge today. In many cases the organizational and semantic language issues need a lot more focus. If we are going to see governments meet the goals of common and unified service delivery then we really need to see more work in these two areas, and accept that the evolution of the internet has resolved many of the technical challenges that we set out to solve in London ten years ago.