Successful and mature e-government can only be achieved through a process of building organisational infrastructures that enable innovative action strategies to thrive in the culture of interoperability.
Architecture, not technology, should be the main driver in the modernisation of government. Enterprise Architecture is about integrating business strategy planning and IT strategy. Basically, the message is that we must focus less on IT, per se, and more on the process of organising and managing IT across government agencies.
From ‘Enterprise Architecture for e-government’, John G�tze in IDA Report 21 – March 2004 (download PDF) and IDA eGovernment Newsletter n�7 – March 2004
I want to follow up a bit on this idea of a culture of interoperability in eGovernment. Interoperability is, perhaps especially in Europe, a burning issue everywhere (at least everywhere I go …).
In the European Interoperability Framework, we say that there are three important aspects we need to tackle: organisational, semantic and technical interoperability.
Organisational interoperability is concerned with defining business goals, modelling business processes and bringing about the collaboration of administrations that wish to exchange information, but that may have a different internal organisation and structure for their operations. Moreover, organisational interoperability aims at addressing the requirements of the user community by making services available, findable, accessible and user-oriented.
Semantic interoperability is concerned with ensuring that the precise meaning of exchanged information is understandable by any other application not initially developed for this purpose. Semantic interoperability enables systems to combine received information with other information resources and to process it in a meaningful manner.
Technical interoperability covers the technical issues of linking up computer systems and services. This includes key aspects such as open interfaces, interconnection services, data integration and middleware, data presentation and exchange, accessibility and security services.
These aspects of the issue can be taken further, it occurs to me. In our white paper, we talk about five important principles interoperability, openness, security, flexibility and scalability – for an enterprise architecture. We have been trying to consolidate these principles for a while, and have good support for this, but keep meeting requests for more explanation and direction signals. So here is an idea. For each of these principles, we look at the same three important aspects that we need to tackle:
- organisational, semantic and technical interoperability
- organisational, semantic and technical openness
- organisational, semantic and technical security
- organisational, semantic and technical flexibility
- organisational, semantic and technical scalability
Does this work? I think so:
– organisational openness: transparency, democratic openness
– semantic openness: use of open data definitions, access to data issues
– technical openness: use of open standards for data access, access to source code, etc
– etc
My PhD-student Kristian is working on an interesting model about interoperability. So far, the model is two-dimensional, but it might soon become three-dimensional 😉
2 Comments.
Enterprise architecture in the driver’s seat…
John Gøtze quotes himself, then explains further the benefits to governments of developing an enterprise architecture first and foremost. The technology will follow. That business goals and processes should drive technology sounds so very sane and smar…
John, I’m a little lost here. Of cause I agree with you in your observations in the IDA-report. The break down is rational too. However – regarding the first bullet of the ”important aspects”; organizational interoperability. It seems to me that there are somewhat mixed interpretation of, what that bullet includes. When I read EIF a couple of weeks ago, it struck me, to what extent the understanding of ”business” equals the owner of the system. Having read EIA, I’d think you were talking about how to safeguard the interests of the system owner: State, local authority, etc., when you talk about meeting business goals, and modeling business process,
On the other hand, in the OIO white paper, you seem to include the end user (in a public service typically the citizens) and her/his goals in the definition. This understanding is very much in line with how project development and use of IT in general is understood in the realm of information architecture (which is my department).
But I ask myself – and now you: Are we in Denmark in step when it comes to finding the balance between taking care of both system owners (gov. and employees) and users (citizens) interests?
Stig Andersen
Info-Ark