<figure><img src="image_1.png" /></figure>

HAL
open science

# Interoperability, Enterprise Architectures, and IT Governance in Government

Hans Jochen Scholl, Herbert Kubicek, Ralf Cimander

<figure><img src="image_2.png" /></figure>

## ► To cite this version:

Hans Jochen Scholl, Herbert Kubicek, Ralf Cimander. Interoperability, Enterprise Architectures, and IT Governance in Government. 10th Electronic Government (EGOV), Aug 2011, Delft, Netherlands. pp.345-354, 10.1007/978-3-642-22878-0_29. hal-01589076

HAL Id: hal-01589076

https://inria.hal.science/hal-01589076

Submitted on 18 Sep 2017

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_3.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Interoperability, Enterprise Architectures, and IT
Governance in Government

Hans Jochen Scholl<fnref n="1" /> Herbert Kubicek<fnref n="2" /> & Ralf Cimander<fnref n="2" />

**Abstract.** Government represents a unique, and also uniquely complex, environment for interoperation of information systems as well as for integration of workflows and processes across governmental levels and branches. While private-sector organizations by and large have the capacity to implement “enterprise architectures” in a relatively straightforward fashion, for notable reasons governments do not enjoy such luxury. For this study, we evaluated 77 successful projects of government interoperation and integration from across Europe and found that the governance of highly interoperated information systems needs very close attention not only from a functional point of view, but also from a more general-policy perspective. If unchecked, interoperation and integration in government might have the potential to offset or neutralize important safeguards put in place by the constitutional design of separated powers and checks and balances. We found that IT governance might play a more important role than commonly acknowledged and could even provide important clues for informing potential changes in the model of democratic governance in the 21st century.

## 1 Introduction

The Western model of governance, that is, government “of the people by the people and for the people” [13], is built on some core principles, which among others include the principles of limited government, separation of powers, checks and balances, judicial review, and the rule of law [3]. The implementation of these principles in practice has led to a type of government, which is effective, but unlike private enterprise deliberately not geared towards efficiency and gain. As a consequence, whenever a policy problem transcends the mandate and jurisdiction of a given governmental entity, this entity along with all other agencies and parties involved in the problem need to co-determine an outcome, which satisfies their respective needs. This process can be repetitive and tiresome; however, such inefficiency was intended by constitutional design.

Whenever separate jurisdictions intend to exchange information, in many cases laws, statutes, or regulations limit such exchange; or, the exchange might hinge upon the approval of individual government officials on a case-by-case basis. Typically, the process was slow and cumbersome. Despite the advent of modern information and communication technology (ICT), nothing much changed this state of affairs until the Internet made possible the effective connection of diverse information systems. At the end of the 20th century, governments also began more systematically connecting and

<footnote n="1">¹University of Washington, Seattle, USA</footnote>

<footnote n="2">²University of Bremen, Bremen, Germany</footnote>

<footnote>jscholl@uw.edu; [kubicek, cimander]@ifib.de</footnote>
interoperating their ICTs (please note that henceforth we will interchangeably use the acronyms *ICT* and *IT*, that is, information technology). It soon became clear in that process that sustainable and effective inter- and intra-governmental interoperation required more than just the technical connectivity via some smart middleware [4]. In many cases, administrative, statutory, and legal rearrangements had to be made. However, quite a few interoperation projects appear to have flown underneath the radar screen of public scrutiny, evaluation, and approval. We believe that the latter projects have been carried out as mere "technical" projects with little public visibility and attention. While we favor the improvement of government operations by means of modern ICT, we are also afraid of a mere technocratic understanding and implementation philosophy permeating and determining the model of governance.

The paper is organized as follows: We first briefly review the extant literature on interoperability, IT governance, and enterprise architectures in government. Then, we pose our research questions and detail the methodology used. Next, we present our findings followed by a discussion and an outlook on future research.

## 2 Brief Review of Related and Relevant Literatures

*Interoperability* has been distinguished from the act of *interoperation* as the capacity to engage in interoperation [15], that is, the more capable processes and systems are to engage in interoperation, the more they are interoperable (ibid). If such interoperability allows for ad-hoc interoperation based on adherence to standards and norms of operation, then such processes and systems are called highly interoperable (ibid). According to the authors interoperation and interoperability are distinct from *integration* (ibid). While the former refer to system and network-related aspects of operation, the latter encompasses the organizational and governance side of operation on process and workflow levels. This in turn can lead to tightly coupled, interoperable, and "integrated systems" on all levels. As Chen et al [5, p. 648] put it, "two integrated systems are inevitably interoperable; but two interoperable systems are not necessarily integrated." Various frameworks have been proposed to define the dimensions of *interoperability* [5], for example, as ability to exchange and use information between information systems [9, 18], or the exchange of information based on adhered-by standards [2]. The European Commission distinguished technical, semantic, and organizational interoperability [1]. Yet, others break down the technical level into a low-level technical protocol level and a higher-level syntactic level. When synthesizing the various frameworks, four levels of interoperability emerge, (1) the (low-level) technical level, (2) syntactic level, (3) the semantic level, and (4) the organizational level, the four of which form a hierarchy. Part of the semantic and the organizational levels encompass what Scholl and Klischewski [15] have referred to as integration.

*Enterprise architectures* have emerged in the private sector over the past decades in order to more effectively utilize and coordinate enterprise resources and enterprise-wide decision-making [11, 16]. Such architectures have been the underlying concept for designing enterprise systems, for example, enterprise resource planning (ERP) systems. Although enterprise systems regularly interoperate well on lower technical levels, for the lack of common architectural standards, which would encompass all levels of interoperation (including the process, structural, and strategic levels) leading to high degrees of process and system integration, enterprise systems still do not satisfactorily interoperate on those higher levels of process and business [5]. The aforementioned interoperability frameworks attempt to fill this gap, however, with observably limited efficacy (ibid). Enterprise architectures in the public sector have been no
exception to this observation [7]. Since government is markedly distinct from private
enterprise, the more appropriate term for the public-sector context would be “institu-
tional architecture.” Where enterprise systems and architectural standards were im-
posed in the public sector, problems from resource asymmetries, redundancies (for
dual processing), and rigidities of operation and in terms of future development have
been reported [10]. Beyond these constraints several other constraints to interopera-
tion and integration have been discussed such as legal, jurisdictional, collaborative,
organizational, informational, managerial, cost, technological, and performance con-
straints [15]. Governance of interoperability and institutional architectures, hence,
extends beyond the technical realm.

*Public-sector IT Governance* has not yet been defined in a widely accepted fashion in scholarly research. However, on a general plain, (public) *governance* has been defined “as regimes of laws, administrative rules, judicial rulings, and practices that constrain, prescribe, and enable government activity, where such activity is broadly defined as the production and delivery of publicly supported goods and services.” [14, p. 235]. When transposing this broad definition of governance to public-sector governance of IT, one could define IT governance as “regimes of IT-related standards, agreements, methods, rules, and practices that constrain, prescribe, and enable the implementation and use of ICTs to support government activity.” Other scholars have proposed definitions, which in part overlap our definition, which heavily leans on Lynn and friends’ more general definition (cf., [17, 19]). Important elements of public-sector IT governance, hence, also include the concepts and practices of standardization and centralization, which Child had juxtaposed in his discussion of strategic choices [6]. In the context of decentralized systems operated by relative independent organizational entities as typical in government, the adherence to standards is a prerequisite for any basic interoperability, which, however, also predetermines a certain model of participative and consensual IT governance that cannot rely on any central command and control outside jurisdictional boundaries [5, 7].

In summary, as demonstrated above interoperability, institutional (or enterprise) architecture, and IT governance are closely intertwined phenomena, which have not been systematically documented in the academic literature, and whose relationships are not fully understood in the public-sector context. Institutional architectures have to encompass the principles and define the mechanisms and levels of interoperability. The institutional architecture and principles, mechanisms, and levels of interoperability, in turn, are subject to the governance models of an institution and its IT. Once those principles, mechanisms, and levels are observed, architectures and IT governance models can be inferred. Also, conversely, given the model of institutional governance, institutional architectures as well as the principles, mechanisms, and levels of interoperability can be assessed with regard to their respective suitability and compatibility.

**3 Research Questions and Methodology**

*Case Method.* In the absence of any comprehensive study on the subject in the area of government, we pursued a multi-stage exploratory approach, in which cases of interoperability in government were identified, systematically documented, and analyzed. These cases were further scrutinized regarding indicators for institutional architectures and governance structures. We first performed qualitative and quantitative in-case analyses followed by comparative cross-case analyses.
*Study Question.* For reasons of space constraints in this paper we present our high-level research question as,

(RQ) What are the characteristics of interoperability projects in government, also in terms of institutional architectures and governance structures, and how do they match up?

*Sample.* We identified and were able to validate a total of seventy-seven cases of interoperability projects in the public sector from all across the European Union. These “good practice” cases contained sixteen back-office studies, thirty “eEurope Award” good practice cases, six Terregov study cases, and twenty-five good practice cases based on national nominations (please see http://www.egov-iop.ifib.de/). These interoperability cases broke down into thirty-one cases of specific services, seventeen integration cases, six infrastructure development cases, and twenty-three portal development cases. In terms of geographical breakdown seventeen cases were taken from Northern Europe (Denmark, Estonia, Finland, Iceland, Norway, and Sweden), seven cases from Eastern Europe (Bulgaria, Hungary, Montenegro, Poland, and Romania), another seventeen from Southern Europe (Greece, Italy, and Spain), eighteen cases from Central Europe (Austria, Czech Republic, Germany, and Switzerland), and another eighteen cases were found in Western Europe (Belgium, France, Ireland, the Netherlands, and the United Kingdom). With regard to the level of government, forty-six cases were located at the national or federal levels, four cases encompassed multiple regions (or federal states), fifteen cases were found on the regional (or state) levels, five cases involved multiple local governments, and seven cases pertained to the level of local government.

The sample size and the case distribution seem to be fairly representative. However, all cases had been either nominated or proposed as “good-practice” cases, which creates a strong sampling bias in this study towards somewhat “good” and successful interoperability cases. When discussing the generalizability of our results, we will reemphasize this sampling bias.

*Data Collection.* In previous rounds of study, comprehensive and systematically structured case reports had been created, which were used as base input data to this study (please see http://www.egov-iop.ifib.de/). For eighteen cases, which stood out in terms of centralization, standardization, or semantic interoperability, further in-depth interviews with project owners and project members were conducted. As a next step, some forty experts from across Europe were invited to discuss these eighteen cases in a number of workshops. The data generated from the original case reports, the additional interviews and workshops were then compiled into extended case reports, which we then also used for this study.

*Data Analysis.* Case reports were analyzed in terms of the aforementioned four layers of interoperability (technical, syntactic, semantic, and organizational/business process) as well as (along these layers) in terms of the implementation, that is, the extent of standardization and, as an alternative, centralization. The coding was based on interoperability criteria and elements shown in Table 1. We employed a scalogram approach [8] in order to inductively verify whether or not the structures we found in the data were cumulative. These so-called Guttman scales indicate how strong a cumulative structure under study is. In other words, the occurrence of the higher level makes the existence of the lower layers in the structure more likely the more the overall structure is a cumulative one.
<table><caption>Table 1. Analytical breakdown of interoperability (IOP) levels</caption><thead><tr><th>Interoperability Layer</th><th>Characteristics</th><th>Objects</th><th>Implementation</th><th>Examples</th></tr></thead><tbody><tr><td>Business Process IOP</td><td>Automated processing between different business processes</td><td>Workflows</td><td>Architectural models</td><td>SOA with WSDL, BPML</td></tr><tr><td>Semantic IOP</td><td>Automated recognition of individually received data</td><td>Information</td><td>Common directories, data keys, ontologies</td><td>EAN location number, UPC (Universal Product Code)</td></tr><tr><td>Syntactic IOP</td><td>Automated recognition of certain classes of objects</td><td>Data</td><td>Standardized data exchange formats</td><td>EDIFACT; XML</td></tr><tr><td>Technical IOP</td><td>Technically secure data transmission</td><td>Signals</td><td>Protocols of data transfer</td><td>HTTPS, SMTP</td></tr></tbody></table>

## 4 Findings

*Hierarchy of Interoperability Layers.* As indicated above, according to theory we expected to find the four levels of interoperability to represent a hierarchical structure, in which the next higher and more specific level of interoperability rests on the previous less specific one. As a consequence, higher layers of interoperability should not be found when lower levels were absent. Such a hierarchical structure would fit the definition of a so-called cumulative structure. In fact, in the vast majority of the cases, we were able to identify at least the lower two or three of four interoperability layers. The scalogram analysis [8] showed a strong cumulative structure (see Table 2) with a reproducibility coefficient of 0.987 (reproducibility coefficient = 1-(number of errors/number of cases*number of items)).

In fact, only four cases do not expose the overall pattern of cumulative interoperability layers. In all four cases, interoperability has been achieved on the business process level without a semantic interoperability layer underneath. However, this type of business process interoperability is achieved at the expense of “hard-wired” rigidity of process to use a technology term. When disregarding the four special cases, the four layers of interoperability have been found implemented in almost all cases forming an almost perfect Guttman scale.

We would like to remind the reader that the 77 cases were identified as good-practice cases. In other words, it appears that the vast majority of good practice cases follow a layered architectural approach. In the absence of failure cases in this study, we cannot be sure, but we would not be awfully surprised to find this architectural principle of interoperability as a key success factor for successful interoperability projects in future research.
<table><caption>Table 2. Summary scalogram of 77 IOP cases</caption><thead><tr><th>IOP Layers</th><th>Number of Cases</th></tr></thead><tbody><tr><td>IOP Layers 1 to 4</td><td>40</td></tr><tr><td>IOP Layers 1 to 3</td><td>20</td></tr><tr><td>IOP Layers 1 to 2</td><td>13</td></tr><tr><td>IOP Layer 1</td><td>0</td></tr><tr><td>IOP Layers missing</td><td>2</td></tr><tr><td>No IOP Layers</td><td>2</td></tr><tr><td>n =</td><td>77</td></tr></tbody></table>

*Standardization and Interoperability.* In a completely decentralized IT environment, interoperability would be possible when two conditions were met (a) for every recurring exchange a specific exchange procedure needed to be established ex ante. This would be tiresome and costly if the demand for new exchanges increases; or, (b) interoperability would be enabled by means of standardization of exchanges (as, for example, via standardized protocols and procedures as prescribed by the four layers of interoperability. With perfect adherence to standards, hence, new exchanges would be implementable with relative ease. We were interested in what standards we would find in the cases with regard to the various interoperability layers. It was clear from the outset that we would sure find basic routing and directory services on the technical level. However, in the syntactic layer, we looked for data exchange formats such as EDIFACT or XML, in the semantic layer we expected to find data keys and ontologies for data fields, and in the business process level, we looked for workflow definitions based on common description languages.

Following the layered hierarchy, we hence found directory service definitions, data exchange format definitions, data key definitions, and workflow definitions. Table 3 shows the distribution of standards across the interoperability layers. For the thirty-one cases of specific government services, we found twenty-eight cases with a perfect Guttman scaling structure, twenty-three of which exhibited the standardization elements on each layer. The reproducibility coefficient of 0.9355 (all cases) and of 0.9677 (special government services) showed an almost perfect cumulative structure for these cases.

*Centralization and Interoperability.* When IT services are provided centrally, standards can but do not have to be used for providing interoperability. We found a number of centralized vehicles used for facilitating interoperability, which were not based on public standards such as (a) centralized directories for address translation and message routing (which we found in 62 of 77 cases and in 27 of the 31 specific government service cases), (b) centralized directories for user authentication (60/77 and 23/31), and (c) so-called core directories for data keys used in message data fields (38/77 and 14/31). We also found some centrally provided process functions, (d) data format conversion (33/77 and 17/31), (e) process control such as format validation, tracking, or tracing (55/77 and 25/31).

*Select Observations.* Elsewhere, we identified interoperability requirements as (a) multi-service exchanges when common data are exchanged for different services, (b) multi-stage exchanges when workflows occur between different stages of a service, (c) multi-area exchanges when data are exchanged between units in different geo-
graphical areas, and (d) multi-file exchanges when common services are provided for different files [12]. We cross-tabulated these interoperability requirements with the respective standards identified on the four interoperability layers and found for the 31 specific government services complete standardization for data exchanges (syntactic layer), and very high standardization also for data keys (semantic layer) and work-flows (business process layer). However, standardization was relatively weak for directories (technical layer). When we analyzed how the interoperability requirements were met via centralization, we found that centralization was high to very high for address directories and process control, however, relatively low for authentication directories and core directories, and medium for conversions.

*Permanent and/or temporary institutions.* IT governance encompasses the assign-ment of authority for planning and controlling of IT infrastructures and services to organizational and functional units. In inter-governmental interoperability projects it was not always clear from the outset, which units had been assigned to planning the various options. Scholl and Klischewski [15] mention federations as more permanent configurations and working groups for more loosely-connected projects. In our sam-ple we found different governance structures in the various phases of a given project life cycle. In the planning phase, the task of planning for interoperability assigned to either existing or new, and, either permanent or temporary institutions. If interopera-tion between already existing government services had to be established mostly exist-ing institutions orchestrated the cooperation between the agencies involved because these existing institutions were able to build upon their experience in planning elec-tronic exchanges. Wherever integration of processes was required between agencies spanning branches and levels of government and no previous collaborative relation-ship had pre-existed, new temporary institutions were formed such as project groups. Only in a single case a new permanent institution was formed where a clearinghouse for the whole social security sector (in Belgium) had to be created.

*IT Governance: Agreements, Ordinances, and Adherence to Standards.* If not cen-trally governed, that is, controlled by law or ordinance and enforced by monitoring or budgetary means, interoperability frameworks, standards, and institutional architec-tures are only as effective as the various parties involved adhere to them. Scholl and Klischewski [15] have argued that the more government agencies operate in an inte-grated fashion, the more they need formal agreements ensuring that modes and stand-ards of interoperation on all levels are adhered to. When we inspected the data regard-ing the arrangements for enforcing the compliance with ordinances and/or the adher-ence to standards as well as to an agreed upon model of IT governance, we were able to identify mandatory standards in 14 of 31 specific government services, while 17 of 31 cases were based on recommended standards. Whereas mandatory standards had mostly been enacted by law (10 of 14 cases), quite many recommended standards had been established via agreements or contracts. While such outcome was expectable, we found it surprising that standards when sanctioned via formal agreements between collaborating partners still were found mandatory in only four cases and recommend-ed in the other twelve. Obviously, in most cases signatories do not completely enact what they had agreed upon. Adjusting existing legacy systems to standards might have proven to be expensive, so that the signatories appeared to have opted in favor of greater flexibility.
# 5 Discussion and Summary

We set out to investigate the characteristics of interoperability projects in government. In 77 overall cases, and more so, among those in the 31 cases of specific government services, we found that in these projects the various layers of interoperability (technical, syntactic, semantic, and business process) were specifically addressed. Particularly, on the higher layers high degrees of standardization were found across the cases, especially, in the 31 specific government service cases. This high degree of standardization is complemented by some degree of centralization of various services such as address directory service and process control. Interoperability in technical and functional terms appears to be ever better understood and executed in practice. The high use of standardized approaches also indicates that public-sector IT leadership understands the benefits of so doing. We would, however, like to reemphasize that these results are based on 77 cases of evidently “good-practice” interoperability in government. We explicitly refrain from inferring that standardization (complemented by some degree of centralization) in government interoperability makes project success more likely. As Scholl and Klischewski [15, p. 911] suggested, we would need to analyze not only unproblematic outcomes as in this study but also problematic outcomes of *type A* (unsuccessful project aiming at desirable project goals) identifying the failure causes, and of *type B* (successful projects producing undesirable results) analyzing the sources and causes of undesired side effects.

For a type-B problematic outcome analysis, the 77 case reports rendered too little insight for us to make any qualified statement on that ground. However, what we noticed was an at least unmindful approach to transferring architectural (and that means, governance) principles from the private sector into government. Public-sector IT governance might incorrectly be interpreted as a purely technical and functional affair, which it is not. The laws and ordinances as well as the collaborative agreements regarding institutional architectures and IT governance models used by collaborating government agencies need to be carefully reviewed and assessed.

As mentioned above a linchpin in the Western-style model of governance is the notion that government needs to be and stay limited; and, in order to assure that government stays within those constitutionally designed explicit limits several safeguards have been devised such as the division of governmental powers and a system of checks and balances, as we pointed out in the introduction. However, interoperability, and, hence, the public-sector IT governance thereof, needs to be pursued by upholding these constitutional principles.

Our research results from these seventy-seven “good-practice” cases, that is, cases of successful interoperation in government, highlight that a successful model of governance of interoperability for a project in one area of government does not easily transfer to projects with other services in different areas, levels, and branches of government. We were able to describe and systematize the processes and instruments for establishing interoperation in the public sector. Also, we developed an empirically grounded framework for the governance of interoperability in government. However, we caution that the high-level categories in this framework have to be broken down and adopted to the respective context in any given interoperability project. Although
seemingly impossible, it would nevertheless be undesirable to establish a single IT
Governance regime across all sectors and levels of government. Based on empirical
insight we dismiss the drive for establishing Enterprise Architectures in the public
sector as inappropriate and problematic, at a minimum. Institutional architectures
represent governance structures, and interoperability in the public sector requires
governance structures different from the private sector. Even in industrial conglomer-
ates with formal Enterprise Architectures we know of no cases, in which all affilia-
tions completely adhere to the architecture. For good reasons, powers in the public
sector have been separated and must remain so, in order to maintain the very founda-
tions of the democratic system at large. Our findings show that IT governance needs
to be established anew in each single case of cross-sector and cross-level interopera-
bility. From a constitutional perspective, this is a comforting insight. Yet it will re-
main necessary to check new networked e-services for their capacity to uphold "dem-
ocratic interoperability."

6 References

[1] European Commission, "Communication From The Commission To The European Parliament, The Council, The European Economic And Social Committee And The Committee Of The Regions: Towards interoperability for European public services." vol. COM (2010) 12/16/2010 Brussels: European Commission, 2010, pp. 1-55.

[2] European Public Administration Network eGovernment Working Group, "Key principles of an Interoperability Architecture," Brussels, BE: European Union, 2004.

[3] Anonymous, "The Constitution of the United States," Convention of States, Ed., 1787.

[4] J. Becker, D. Pfeiffer, and M. Räckers, "Domain Specific Process Modelling in Public Administrations – The PICTURE-Approach," in 6th International Conference, EGOV 2007. vol. 4656/2007, M. A. Wimmer, J. Scholl, and A. Gronlund, Eds. Regensburg, Germany: Springer Berlin/Heidelberg, 2007, pp. 68-79.

[5] D. Chen, G. Doumeingts, and F. Vernadat, "Architectures for enterprise integration and interoperability: Past, present and future," Computers in Industry, vol. 59, pp. 647-659, 2008.

[6] J. Child, "Organizational Structure, Environment and Performance: The Role of Strategic Choice," Sociology, vol. 10, pp. 1-22, 1972.

[7] L. Guijarro, "Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States," Government Information Quarterly, vol. 24, pp. 89-101, 2007.

[8] L. Guttman, "A Basis for Scaling Qualitative Data," American Sociological Review, vol. 9, pp. 139-150, 1944.

[9] IEEE Computer Society. Standards Coordinating Committee., IEEE standard computer dictionary : a compilation of IEEE standard computer glossaries, 610. New York, NY, USA: Institute of Electrical and Electronics Engineers, 1990.
[10] S. J. Jackson and R. Chongthammakun, "Infrastructure and standards in Thai digital government," in Proceedings of the 2011 iConference, Seattle, Washington, 2011, pp. 379-386.

[11] K. Kosanke and J. G. Nell, Enterprise engineering and integration : building international consensus : proceedings of ICEIMT &\#x02bc;97, International Conference on Enterprise Integration and Modeling Technology, Torino, Italy, October 28-30, 1997. Berlin ; New York: Springer, 1997.

[12] H. Kubicek, R. Cimander, and H. J. Scholl, Framing the governance of interoperability in e-government. Berlin, Heidelberg, New York: Springer (forthcoming), 2011.

[13] A. Lincoln, "The Gettysburg Address." vol. 2010, 1863.

[14] L. E. Lynn, C. J. Heinrich, and C. J. Hill, "Studying Governance and Public Management: Challenges and Prospects," Journal of Public Administration Research and Theory, vol. 10, pp. 233-261, 2000.

[15] H. J. Scholl and R. Klischewski, "E-Government Integration and Interoperability: Framing the Research Agenda," International Journal of Public Administration, vol. 30, pp. 889-920, 2007.

[16] D. N. Shorter, "Requirements for enterprise model execution and integration services," in Enterprise engineering and integration : building international consensus : proceedings of ICEIMT &\#x02bc;97, International Conference on Enterprise Integration and Modeling Technology, Torino, Italy, October 28-30, 1997. Research reports ESPRIT. Project 21.859, EI-IC v. 1, K. Kosanke and J. G. Nell, Eds. Berlin ; New York: Springer, 1997, pp. xvi, 634 p.

[17] W. Van Grembergen, S. D. Haes, and E. Guldemonts, "Structures, processes, and relational mechanisms for IT governance," in Strategies for information technology governance, W. Van Grembergen, Ed. Hershey: Idea Group Pub., 2004, pp. 1-36.

[18] H. v. d. Veer and A. Wiles, "Achieving Technical Interoperability - the ETSI Approach," 3rd ed. vol. ETSI White Paper No. 3 Sophia Antipolis Cedex, France: European Telecommunications Standards Institute, 2008, pp. 1-29.

[19] P. Weill and J. W. Ross, IT governance : how top performers manage IT decision rights for superior results. Boston: Harvard Business School Press, 2004.