Government Information Quarterly 24 (2007) 89 – 101

Interoperability frameworks and enterprise architectures in

e-government initiatives in Europe and the United States
Luis Guijarro
Communications Department, Technical University of Valencia, Camino de Vera, s/n. 46022 Valencia, Spain

Available online 7 July 2006

Abstract

Public administrations have been very much concerned since the 1980s about the need of avoiding
vendor lock-in when procuring themselves with information technology (IT) infrastructure. The boost
of e-government that has taken place in recent years has put this concern again in the agenda of public
administrations. Interoperability has shown up as a principle in the conception and deployment of the
e-government initiatives, and the interoperability frameworks have been the tool for implementing the
principle. In this paper, the use of the interoperability frameworks and of the enterprise architectures
within the e-government initiatives is surveyed. The scope of the survey is Europe and the United
States. As far as the author is aware, all trends in interoperability policy fall within the scope of the
survey. The survey is focused on the methodological tools that e-government agencies have devised
for achieving the interoperability at the public administrations. The tools are interoperability
frameworks and enterprise architectures.
D 2006 Elsevier Inc. All rights reserved.

1. Introduction

In the late 1990s, most governments in the Organisation for Economic Co-operation and
Development (OECD) countries released their e-government strategies. These e-government
strategies were supported by their own framework policies, covering security, confidentiality,

E-mail address: [email protected].

0740-624X/$ - see front matter D 2006 Elsevier Inc. All rights reserved.
doi:10.1016/j.giq.2006.05.003
90 L. Guijarro / Government Information Quarterly 24 (2007) 89–101

delivery channels, etc. One of such policies was the interoperability policy (CEC (2002),
(p. 10); OECD (2003), (pp. 62, 99)).
Interoperability between computing components may be generally defined as bthe ability
to exchange information and mutually to use the information which has been exchanged.Q
(CEC, 1991) An interoperability framework aims at referencing the basic technical
specifications that all agencies relevant to the e-government strategy implementation should
adopt. This interoperability framework should enable, at least, the interoperability between
information systems from different agencies in order to provide services to citizens and
businesses in an integrated way.
In this paper, the use of the interoperability frameworks and of the enterprise architectures
within the e-government initiatives is surveyed. The scope of the survey is Europe and the
United States. As far as the author is aware, all trends in interoperability policy fall within the
scope of the survey. The survey is focused on the methodological tools that e-government
agencies have devised for achieving the interoperability at the public administrations. The
tools are interoperability frameworks and enterprise architectures.
The structure of the paper is as follows. In the following section, a historical background is
laid out. In Section 3, some of the e-government initiatives that have worked deeply in the area
of interoperability are presented, and the interoperability frameworks that they have produced
are described. Next, in Section 4, the technical standards that each interoperability framework
covers are described. In Section 5, the enterprise architecture is presented as a tool for achieving
interoperability at an organizational level. Finally, some conclusions are formulated.
The paper is part of a broader research effort investigating the use and utility of the
interoperability frameworks for e-government that has been conducted by the author, and the
first results of which were published in Guijarro (2004, 2005). The participation of the author
in several working groups has nurtured this research, namely the E-Forum Association,1
which carried out a study, from January to September 2003, of the interoperability issues
of the shared infrastructures that support the delivery of e-government services; the European
Union-funded MODINIS Lot 2 Study on interoperability at regional and local level2 for the
2005–2007 period; and the European Committee for Standardization (CEN) Focus Group on
eGovernment,3 setup in October 2004. As an application of the research, an analysis of the e-
government initiative4 of the Regional Government of Valencia (Spain) was undertaken
during 2004 and 2005. The analysis covered both the strategic and the technical viewpoints.
As a tangible result of the analysis, an interoperability framework was generated by the
Telecommunications and Information Society Department of the Regional Government of
Valencia and the deployment through the full range of Departments is in the planning phase.
There are many of publicly available documents describing the e-government initiatives
and their policies. Nevertheless, there are few works that analyze the grounds of the initiatives
and their policies. Furthermore, both public organizations, like the United Nations (2003) and

1
Visit http://www.eu-forum.org.
2
Visit http://www.egov-iop.ifib.de.
3
Visit http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/activity/e-government.asp.
4
Visit http://www.avantic.es.
 L. Guijarro / Government Information Quarterly 24 (2007) 89–101 91

the OECD (2003), and private firms, like Accenture (2004), have generated comparative
studies analyzing the e-government initiatives. However, these studies do not tackle the
concrete policies that implement the initiatives, and they aim to track the progress of the
initiatives by means of surveys and statistics. There is a lack of studies that provide
comparative analyses that focus on the methodologies and on the concrete policies being
carried out. This paper intends to fill the gap. It specifically tackles interoperability policy. In
addition, this paper tracks the historical background of these policies and it intends to link
current policies with the practice of public administration in information technology (IT) back
in the 1980s, specially in the case of the United States.

2. Background

Public administrations have been very much concerned about the need of avoiding vendor
lock-in when procuring IT infrastructure. This concern met a response in the 1980s by means
of the standardization. Standardization was a typical response in the 1980s to the concerns
related to interoperability and proprietary systems.
In 1984, the International Organisation for Standardization (ISO)5 produced the Open
Systems Interconnection (OSI) Reference Model and standards, which helped governments in
the area of networking. The existing information systems networking technology was
typically developed as proprietary systems, and interoperation between these systems was
non-existent. Additionally, there was a demand for standards to facilitate cooperating
processes and applications independent of platforms.
The National Institute of Standards and Technology (NIST) in the United States approved
the bGovernment Open Systems Interconnection Profile (GOSIP)Q in 1988 as FIPS 146, and it
described the situation as follows:
Both the government and the private sector recognize the need to develop a set of common data communication
protocols based on the International Organization for Standardization’s seven-layer Open Systems Interconnection
(OSI) Basic Reference Model. In the past, vendor-specific implementations of data communication protocols led to
isolated domains of information, very difficult and expensive to bridge. Recent advances in communication technology
based on the OSI model offer alternatives to vendor-specific network solutions. Most significantly, advances in open
systems allow the interoperation of end systems of different manufacture, when required NIST (1990), (p. 1).

From that, NIST put forward the GOSIP with the following objective:.
This profile is the standard reference for all federal government agencies to use when acquiring and operating ADP
[Automated Data Processing] systems or services and communication systems or services intended to conform to ISO
Open Systems Interconnection protocols which provide interoperability in a heterogeneous environment NIST (1990),
(p. 1).

Indeed, the U.S. federal government showed a strong commitment to OSI and GOSIP.
GOSIP was to be used by federal agencies ready to proceed with acquisition of OSI networks.
Even the Department of Defense (DoD) was taking the lead in requiring GOSIP in future

5
Visit http://www.iso.org.
92 L. Guijarro / Government Information Quarterly 24 (2007) 89–101

network acquisitions. In 1987, the DoD issued a policy statement outlining the shift from the
current department protocol set (Transmission Control Protocol/Internet Protocol, TCP/IP) to
OSI. TCP/IP was the protocol set that is the foundation of the current Internet. For a two-year
period, the TCP/IP and OSI protocols would be co-standards; after two years, OSI protocols
would be used in acquisitions (Radack, 1988). Some years later, however, NIST (1995)
approved a revision on GOSIP with the title bProfiles for Open Systems Internetworking
TechnologiesQ (POSIT). In POSIT, the lack of OSI-based products and services and the
growth of Internet (i.e., TCP/IP based network) were acknowledged, and consequently, the
revised standards broadened options for agencies by enabling them to acquire and use a
variety of networking products that implement open, voluntary standards. Such standards
included those developed not only by ISO, but also by the Internet Engineering Task Force
(IETF), for instance.
The U.S. GOSIP was intended as a procurement guideline for government departments to
ensure that systems separately acquired would be able to interwork. In the United Kingdom,
while similar to the U.S. GOSIP specifications, the UK GOSIP was oriented more toward
user applications, rather than back-end systems, and providing technical assistance to help
users in the procurement process of desktop applications.
At the level of the then European Community, now European Union, the Commission
developed the European Procurement Handbook for Open Systems. It was based largely on
the UK GOSIP specifications with contributions from France and Germany. In Europe, a
great deal of emphasis was placed on defining standardized profiles, similar to the U.S.
GOSIP, for two reasons. First, the European market was characterized by a larger number of
computer manufacturers than in North America, resulting in more interworking difficulties.
The other strong impetus was the need for interworking among Members States (Hartmann,
1990).
Like in the networking area, similar effects were produced in the area of computing when
the Institute of Electrical and Electronic Engineers (IEEE)6 and ISO approved the POSIX
standard (Portable Operating System Interface) in 1992 and ISO approved the ODP (Open
Distributed Processing) Reference Model in 1996, after a decade of standardization work.
Recently, the rise of e-government has put the above concerns again on the agenda of public
administrations. Now, concern is shared worldwide, and European agencies, in particular, have
shown up in the discussion and the search for solutions. Large investments have been made in
IT procurement in public administrations for e-government service delivery and policies are
being implemented in order to guarantee that open standards – and sometimes open source
software – are now adhered to by IT vendors. Furthermore, new ways of public service delivery
involving a customer-centric approach – which hides the complexity of the administrative
procedures – and involving a high degree of interaction between local, regional, national, and
European administration have just started to be implemented.
In this scenario, interoperability is clearly a key issue and it has shown up as a principle in
the conception and deployment of e-government initiatives.

6
Visit http://www.ieee.org.
 L. Guijarro / Government Information Quarterly 24 (2007) 89–101 93

3. e-Government interoperability initiatives

This section enumerates and discusses six major initiatives being carried out by e-
government agencies in the interoperability arena, which have produced the corresponding
interoperability frameworks.
In the United Kingdom, the eGovernment Unit7 (eGU), formerly known as Office of the e-
Envoy, has based its technical guidance on the eGovernment Interoperability Framework (e-
GIF), which was issued in 2000, and updated to version 6.1 in March 2005. e-GIF mandates
sets of specifications and policies for any cross-agency collaboration and for e-government
service delivery. It covers four areas: interconnectivity, data integration, e-services access, and
content management (eGU, 2005). The e-GIF contains a Technical Standard Catalogue,
which is revised and updated every 6 months.
The French ADAE8 (bAgence pour le Développement de l’Administration ÉlectroniqueQ)
published bLe Cadre Commun d’IntéroperabilitéQ (CCI) in January 2002, and its last version
(2.1) in September 2003. CCI comprises the recommendations for strengthening public
electronic systems coherence and for enabling multi-agency electronic service delivery
(ADAE, 2003).
Germany’s Federal Government Co-ordination and Advisory Agency for IT in the Federal
Administration (KBSt),9 published the Standards and Architectures for e-government
Applications (SAGA) in February 2003, and updated to version 2.0 in December 2003.
SAGA, which stems from the BundOnline 2005 e-government initiative launched in
September 2000, is a guideline that serves as an orientation aid for decision-makers in the e-
government teams in German administrations (KBSt, 2003).
In Denmark, the National IT and Telecom Agency10 published the first version of an
interoperability framework in 2004 under the name of Danish eGovernment Interoper-
ability Framework (DIF), and its latest version (1.2.10) was released in December 2005.11
DIF is intended as a guideline to public agencies as they develop IT plans and projects.
An important difference of these various frameworks relates to enforcement. The e-GIF
reflects a higher level of enforcement than CCI, SAGA, and DIF. e-GIF is mandatory whereas
CCI, SAGA, and DIF are recommendations and guidelines.
The European Union has set up different initiatives in the area of e-government within the
limits of its powers in the domain of Public Administration (Alabau, 2004). Within the
European Commission, the Directorate-General Enterprise and Industry manages the IDABC
Programme12 (IDABC stands for Interoperable Delivery of European eGovernment Services
to public Administrations, Business and Citizens). As regards interoperability frameworks,
the IDABC Programme issued its Architecture Guidelines (version 4.1) in March 1999, as a
supporting tool for the Decision of the European Parliament and the Council 1720/1999/EC
7
Visit http://www.cabinetoffice.gov.uk/egovernment/.
8
Visit http://www.adae.gouv.fr.
9
Visit http://www.kbst.bund.de.
10
Visit http://www.itst.dk.
11
The online version is available at http://www.interoperabilityframework.info/English/.
12
Visit http://europa.eu.int/idabc/.
94 L. Guijarro / Government Information Quarterly 24 (2007) 89–101

bInteroperability and access to Trans-European Networks for the electronic Interchange of

Data between Administrations.Q Version 7.1 was issued in September 2004 (IDABC,
2004a). These guidelines (hereafter IDABC AG) provide concepts and reference for
optimum interoperability between European Institutions, European Agencies, and govern-
ments in Member States. Furthermore, IDABC published the final version 1.0 of its
European Interoperability Framework (IDABC EIF) in November 2004 (IDABC, 2004b).
IDABC EIF provides a common framework for discussions about interoperability,
pinpointing which interoperability issues should be addressed when implementing pan-
European e-government services. It, however, avoids prescribing any concrete architecture
or standard catalogue, which was to be the main objective of successive releases of IDABC
AG. IDABC AG and IDABC EIF do not cover the same area that the national
interoperability frameworks cover. However, IDABC AG and IDABC EIF are to have an
indirect but strong influence on them, because IDABC develops join working programs
together with the e-government agencies of the Member States.
In the United States, the Federal Chief Information Officers Council13 (CIOC) issued the
Federal Enterprise Architecture Framework (FEAF) in September 1999 (CIOC, 1999). The
concept of enterprise architecture is covered in more detail in the following sections. To
leverage FEAF guidance in e-government implementation, the Federal CIOC endorsed the
Egovernment Enterprise Architecture Guidance (CIOC EAG) in July 2002 for guiding the
e-government projects across the federal government (CIOC, 2002).
Table 1 summarizes the main features of the above e-government initiatives.

4. Technical interoperability

Every interoperability framework defines its own technical standards catalogue. The
catalogue shows the desired technical profile for e-government implementation, and it
enumerates the standards to be followed in each area of technology.
When dealing with pure technology, the interoperability concept may be defined according
to the software discipline, which understands interoperability to be the bability to exchange
functionality and interpretable data between to software entities.Q (Mowbray & Zahavi, 1995)
Issues covered by this concept are usually grouped in two fields:

! Application interoperability, which includes the communications issues, both at the

telecommunications network access level and at the network interconnection level; and the
distributed applications issues, regarding the remote procedure call/method invocation
mechanisms and the public interface exportation/binding.
! Semantic interoperability, which includes both the data interpretation, by means of XML
schemas, and the knowledge representation and exploitation, by means of ontologies and
agents.
13
Visit http://www.cio.gov.
 L. Guijarro / Government Information Quarterly 24 (2007) 89–101 95

Table 1
Interoperability frameworks developed by e-government agencies
Interoperability framework Agency Country Last version Release date
e-GIF eGU UK 6.1 March 2005
CCI ADAE France 2.1 September 2003
SAGA KDSt Germany 2.0 December 2003
DIF ITST Denmark 1.2.10 December 2005
IDABC AG IDABC EU 7.1 September 2004
EAG CIOC USA 2.0 July 2002

Each one of the six e-government agencies under study mandates a full set of standards
which addresses the areas that are relevant to the interoperability, according to the above
classification. Such areas are, for instance, interconnection, data integration, content
management metadata, telecommunication network access, workflow management, group
working, security, document archiving, and so on. Table 2 shows a sample of the eGU e-GIF
and the CIOC EAG standards catalogues.
The six interoperability frameworks show a common feature: Internet and WWW
technologies comprise their core. However, two different approaches can be identified in the
enumeration of standards: e-GIF, CCI, and DIF follow an OSI-centric approach, which
organizes the standards in a layer-like manner; whereas SAGA, IDABC AG, and CIOC EAG
follow a POSIX-centric approach, which organizes the standards around services. Note,
however, that it does not make any difference in the use of the interoperability framework.
Another issue that deserves attention is that different requirements are put over a candidate
technology to be included in the interoperability framework (Guijarro, 2005). On the one
hand, the British eGU and the German KBSt only require that technical specifications should
be open. The fact that a specification should be open only requires it to be publicly available
On the other, the IDABC EIF explicitly requires that the adopted standards should be
qualified as bopen standard,Q and the U.S. Office of the Management and Budget (OMB)
requires them to be bvoluntary consensus standards.Q When a standard, rather than a

Table 2
Standards and specifications mandated in e-GIF 6 and CIOC EAG 2.0
e-GIF 6.1 CIOC EAG 2.0
Interoperability areas Specifications Services Voluntary industry standards
Interconnection IPv4, HTTP, S/MIME Human computer HTML, Symbian
interface services
Data integration XML, XSL, UML, RDF Data interchange services WAP, J2EE,.NET,
Web Services
Content management XML, e-GMS Network services MIME, T.120, H.323
metadata
Access DTV, mobile phone, Data management services JDBC, WebDAV
PDA, smart card
Security services S/MIME, SAML
96 L. Guijarro / Government Information Quarterly 24 (2007) 89–101

specification, is said to be open, more requirements are meant to be met. However, there is
not a unanimously agreed definition of bopen standard.Q The OMB defines a voluntary
consensus standard as one that emerges from an standards body that embodies the attributes
of openness; balance of interest; due process; an appeal process; and consensus (OMB,
1998). IDABC goes further when it adds intellectual property requirements to an open
standard; IDABC states that bintellectual property – i.e., patents possibly present – of (parts
of) the standard is irrevocably made available on a royalty-free basisQ (IDABC, 2004b).

5. Enterprise architecture role in interoperability

The consensus around a single standard profile in each government is essential for e-
government implementation success because it enables the seamless information flow
between institutions. However, a single standard profile or framework is not enough for
enabling the sort of interoperability required for a true seamless service delivery to citizens
and business, which is the vision of the e-government strategies. Guidance beyond the
technical issues is needed, addressing for example organizational issues. In this effort,
concepts such as enterprise architecture can play a fundamental role.
Enterprise architecture refers to a comprehensive description of all the key elements and
relationships that make up an enterprise. In this definition, an enterprise may be a company, an
institution, or a department within a company or an institution. The elements to be described
may be data, network equipment, software components, business locations, human resources,
etc. Enterprise architecture aims at aligning the business processes and goals of an enterprise
and the applications and systems that constitute its technical infrastructure. There are many
different approaches to describing the elements of an enterprise architecture (Schekkerman,
2004). One approach that has grown in popularity in the past decade is based on a framework
developed by John Zachman (1987). The Zachman Enterprise Architecture Framework
organizes the descriptive representations of an enterprise in a matrix. Each cell in the matrix
represents the intersection of a particular focus (data, function, network, people, time, and
motivation) and a perspective (contextual, conceptual, logical, physical, and out of context).
Each focus relates to one of the Aristotelian questions bwhat, how, where, who, when and why.Q
Each perspective relates to one of the following roles: the planner, the owner, the designer, the
builder, and the subcontractor. Finally, models (e.g., business models, data models, object-
oriented models) are the language of the framework and are contained within the cells. For
example, a business process model may be used for describing the enterprise from the
conceptual perspective and the function focus, whereas describing the enterprise with the same
focus but from the logical perspective; that is, the perspective of the designer, may be better
fulfilled by an application architecture. Note, however, that the Zachman Framework does not
prescribe any process or set of models to be used when implementing the framework.
Not all the e-government agencies examined have addressed the organizational issues, and
not all agencies that have done it have used enterprise architectures. For example, the author
has found that some agencies have only identified that business requirements are an issue to
address, whereas others have already succeed in providing the models and tools for the
 L. Guijarro / Government Information Quarterly 24 (2007) 89–101 97

description of the enterprise, and in founding the technical architecture on this description.
There is no clear explanation for the high diversity in how agencies have addressed the
organizational issues and how far they have progressed in the adoption of enterprise
architectures. In author’s opinion, this diversity relates to how influential is private enterprise
management practices in each e-government agencies. In fact, enterprise architecture is a tool
borrowed from the private enterprise environment, and the commitment of an e-government
agency to use it depends in most cases on the familiarity of the executive officers with this
sort of management practices and tools. This may explain the clear distinction that can be
found between the European and the U.S. e-government agencies.

5.1. Enterprise architecture in Europe

The British eGovernment Unit initially conceived e-GIF as a part of an e-Services

Development Framework (e-SDF). The e-SDF was a framework for guiding and supporting
the development process of e-services in e-government.14 Requirements, design, and
implementation were the three phases of the development process, and the e-SDF provided
two artefacts for assisting the process. At one level, e-SDF provided sets of reusable elements
(patterns, components, and resources) for improving the consistency and reducing costs in the
development at the different phases. At a higher level, e-SDF provided the High Level
Architecture, which was a single set of top-level specifications and standards to be used for
developing government e-Services. The High Level Architecture was composed of the
following:

! The Government Common Information Model (GCIM), which is a high level model of
business activities. Its focus is explicitly on the specification of interoperability
requirements.
! The Government Data Standards Catalogue, which describes the data elements and data
types that are referred to in both GCIM and CMRM.
! The Government Message Reference Model (GMRM), which is a high-level reference
model of information that is exchanged between applications.
! And the e-GIF, which provides the supporting guidelines and technical specifications for
implementation.

The High Level Architecture can be considered as an enterprise architecture framework. The
eGovernment Unit changed this approach when it released version 6, and no mention of the
High Level Architecture has been present in the e-GIF since. Recently, however, the
eGovernment Unit officers have shown a renewed commitment with the development of an
enterprise architecture.
In June 2003, the Danish Ministry of Science, Technology and Innovation published a
white paper on government-wide enterprise architecture (Ministry of Science, Technology
and Innovation, 2003). The white paper recommended that a common enterprise architecture

14
In e-GIF version 6, e-SDF is just regarded as a tool for e-service implementation.
98 L. Guijarro / Government Information Quarterly 24 (2007) 89–101

framework should be developed, and that it would include coordination mechanisms,

methodologies for preparing the enterprise architecture, common choices and principles with
regard to standards and infrastructure, and common tools such as repositories. At present,
progress has been made in the area of common tools and guidance, mainly on the use of XML
and standards, but nothing yet has been published in the area of methodologies.
Both French CCI and German SAGA are still focused on the specification of sets of
standards for guiding the implementation of interoperable applications for the provision of e-
government services, and they have not provided yet a framework for enterprise architecture
description.
The European Commission’s IDABC has shown efforts in progressing towards the
provision of a enterprise architecture, apart from issuing sets of relevant standards for each
service profile. IDABC AG 6.1, the former version of the Architecture Guidelines (IDABC,
2002) regarded two dimensions for guiding the implementation of interoperable e-services:
the business requirements, involving the definition of a suitable implementation approach,
and the security management, involving a security policy that meets the security
requirements and a set of security mechanisms that enforce the policy on the trans-
European network. This three-dimensional model, comprised by the business, security, and
implementation dimensions could form the basis of an enterprise architecture.
Versions later than 6.1 have left the model behind. In 2005, however, there seemed to be a
renewed commitment to enterprise architecture. A study was commissioned by the
Directorate-General Enterprise and Industry to describe the target infrastructure required by
pan-European e-government services and to provide a coherent framework for developing
infrastructure components and managing their interactions (IDABC, 2005). The study was
conducted by CapGemini, and an enterprise architecture was used for guiding the
infrastructure description. This enterprise architecture has been based on the Integrated
Architecture Framework, which is the enterprise architecture framework developed by
CapGemini Ernst and Young (Mcaulay, 2004).

5.2. Enterprise architecture in the United States

In the CIOC EAG, following a different approach from the above e-government initiatives,
applicable standards are only selected for consideration by e-government project teams, but
one enterprise architecture is mandated for all e-government initiatives. In this section, the
prescribed enterprise architecture is presented.
Egovernment implementation in the United States has been highly influenced by the
Clinger–Cohen Act of 1996. The Act shaped federal agencies’ approach to IT acquisition and
management. In particular, it required all federal agencies to establish an architecture program
that integrated a process to select, control, and evaluate their IT investments. Following the
Clinger–Cohen Act, the Office of Management and Budget of the Executive Office of the
President of the United States (OMB) required in 1997 that an IT architecture should be
developed and maintained in agencies (OMB, 1997). As a result, the CIOC published the
Federal Enterprise Architecture Framework (FEAF) (CIOC, 1999). The FEAF was to provide
architecture guidance for federal cross-agency architectures. It is based on the Zachman
 L. Guijarro / Government Information Quarterly 24 (2007) 89–101 99

Framework, and it does not specifies any work products. The FEAF focused on introducing
enterprise architecture concepts and was planned to undergo revision to provide guidance on
architecture work products, a technical reference model, standards, etc.
The CIOC adopted the FEAF as the framework for e-government initiatives (CIOC, 2002),
which comprised four architectures, namely,

! business architecture, which identifies the functions, process, organization, and informa-
tion flow for accomplishing the mission of the organization;
! data architecture, which defines the major types of data needed to support the business, its
meaning, and its form;
! application architecture, which defines the applications and supporting capabilities to
effectively manage the data and information needed to support business objectives; and
! technology architecture, which defines the enabling hardware, software, and their physical
locations to support the business applications/data and functions.

Within each one of the four architectures in the FEAF, the CIOC was to define one or more
models which will guide the development of e-government solutions.
However, the FEAF initiative was never completed. Instead, the emphasis shifted towards
the development of the Federal Enterprise Architecture (FEA) for the OMB. In 2002, OMB
established the FEA as ba business-based framework for cross-agency, government-wide
improvement,Q which consists of five reference models. However, rather than being a
framework, the FEA models are a set of categories that comprise models for defining
business, performance, data, service component, and technical reference; OMB requires
alignment of all departments and cross-agency architecture with the FEA models. The FEA is
the mechanism for the OMB to determine duplications and overlaps in project expenditures,
including e-government initiatives, and take action during the appropriations process in
streamlining certain operations. This has led to confusion since the OMB has redirected the
CIOC’s efforts away from modifying and improving the FEAF, and emphasized the FEA
models in its publications and discussions. As a result, a number of people have mistakenly
assumed that the FEAF is no longer viable and has been replaced by the FEA models
(Bellman & Rausch, 2004).
In our opinion, the FEA shows the highest degree of maturity among the e-government
initiatives under study, since the OMB and the CIOC have not only committed themselves
with enterprise architecture, but they have also defined the models to be used by the
government departments and required the adoption of the models as a condition for budget
approval. Therefore, the chances of success in removing the organizational barriers for
interoperability are high.

6. Conclusions

We have discussed the results of our survey on policy and guidance that e-government
agencies have developed in the area on interoperability. The survey focused on the use of two
100 L. Guijarro / Government Information Quarterly 24 (2007) 89–101

tools, namely, the interoperability frameworks and the enterprise architectures, and this paper
has described and compared the most relevant proposed tools in Europe and the United States.
Based on the results of our research, we may conceptualize a two-phase interoperability
roadmap. A first phase would consist of enabling interoperability, namely, providing the basic
technical standards and policies to enable the seamless flow of information between different
administrations in the delivery of e-services. In this phase, the interoperability frameworks
can be regarded as an appropriate tool. A second phase facilitates the alignment of the
administrative procedures with the technical systems; the result of this alignment contributes
to interoperability at the organizational level between different administrations. In this phase,
the enterprise architecture is a promising tool that the U.S. e-government initiatives have
thoroughly tested and deployed.

Acknowledgments

This work has been supported by the Company, University and Science Department of the
Regional Government of Valencia through the R+D Project GV04A-414.

References

Accenture (2004). eGovernment leadership: high performance, maximum value, May.

ADAE (2003). Le Cadre Commun d’Intéroperabilité version 2.1.
Alabau, A. (2004). The European Union and its eGovernment development policy. Fundación Vodafone.
Available at http://www.upv.es/~lguijar/socinfo/publicaciones_f.htm
Bellman, B., & Rausch, F. (2004). Enterprise architecture for egovernment. Proc. of EGOV 2004 Conference
(48–56). Berlin: Springer (Lecture Notes in Computer Science 3183).
CEC, Commission of the European Communities. (1991). Council Directive 91/250/EEC of 14 May 1991 on the
legal protection of computer programs.
CEC, Commission of the European Communities. (2002), eEurope 2005: An information society for all. An
Action Plan to be presented in view of the Sevilla European Council, 21/22 June 2002, COM (2002) 263 final.
CIOC, Federal Chief Information Officer Council. (1999). Federal enterprise architecture framework, version
1.1.
CIOC, Federal Chief Information Officer Council. (2002). E-Gov enterprise architecture guidance, draft-version
2.0.
eGU, eGovernment Unit. (2005), eGovernment Interoperability Framework, version 6.1.
Guijarro, L. (2004). Analysis of the interoperability frameworks in egovernment initiatives. Proc. of EGOV 2004
Conference (36–39). Berlin: Springer (Lecture Notes in Computer Science 3183).
Guijarro, L. (2005). Policy and practice in standards selection for e-government interoperability frameworks.
Proc. of EGOV 2005 Conference (163–173). Berlin: Springer (Lecture Notes in Computer Science 35917).
Hartmann, U. (1990). Open systems standards: Status of international harmonization and European
activities. Proceedings of the 6th International Conference on the Application of Standards for Open
Systems (pp. 18 – 26). California7 IEEE Computer Society Press.
IDABC, Enterprise and Industry DG. (2002). Architecture guidelines for trans-European telematics networks for
administrations, version 6.1, Brussels.
IDABC, Enterprise and Industry DG. (2004a). Architecture guidelines for trans-European telematics networks for
administrations, version 7.1, Brussels.
 L. Guijarro / Government Information Quarterly 24 (2007) 89–101 101

IDABC, Enterprise and Industry DG. (2004b). European interoperability framework for pan-European
egovernment services, version 1.0, Brussels.
IDABC, Enterprise and Industry DG. (2005). Technical description of target eGov infrastructure for delivering
PEGS. Technology and Market Trends, version 1.2, Brussels.
KBSt. (2003), Standards and Architectures for egovernment Applications, version 2.0.
Mcaulay, A. (2004, January). Enterprise architecture design and the integrated architecture
framework. Microsoft Architec Jounal. Available at http://msdn.microsoft.com/library/en-us/dnmaj/html/
aj1entarch.asp. Accessed April 12, 2005.
Ministry of Science, Technology and Innovation. (2003). White paper on enterprise architecture, Denmark.
Available from: http://www.oio.dk/arkitektur (accessed April 12, 2005).
Mowbray, T. J., & Zahavi, R. (1995). The Essential CORBA, John Wiley&Sons.
NIST. (1990), U.S. Government Open System Interconnection Profile (GOSIP), Version 2.0, FIPS 146 -1. October.
NIST. (1995), Profiles For Open Systems Internetworking Technologies (POSIT), FIPS 146 -2. May.
OECD. Organisation for Economic Co-operation and Development (2003). The Egovernment Imperative . France7
OECD egovernment Studies.
OMB. (1998). Federal participation in the development and use of voluntary consensus standards and in conformity
assessment activities. Revised OMB Circular No. A-119.
Radack, S. M. (1988 June). US government moves toward implementing OSI standards. Computer Magazine,
(IEEE), 82 – 83.
Schekkerman, J. (2004). How to survive in the jungle of Enterprise Architecture Frameworks. Trafford.
United Nations. (2003), World Public Sector Report 2003. Egovernment at the crossroads. October.
Zachman, J. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3).