# Requirements for an Architecture Framework for Pan-European E-Government Services

Ansgar Mondorf, Maria A. Wimmer

► To cite this version:

Ansgar Mondorf, Maria A. Wimmer. Requirements for an Architecture Framework for Pan-European E-Government Services. 5th International Conference on Electronic Government and the Information Systems Perspective (EGOV), Sep 2016, Porto, Portugal. pp.135-150, 10.1007/978-3-319-44421-5_11. hal-01636453

HAL Id: hal-01636453

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

Submitted on 16 Nov 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished 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_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Requirements for an Architecture Framework for Pan-European E-Government Services

Ansgar Mondorf and Maria A. Wimmer

²Institute for IS Research, University of Koblenz-Landau,
Universitätsstr. 1, 56070 Koblenz, Germany
{mondorf,wimmer}@uni-koblenz.de

**Abstract.** Interoperability is a major challenge in providing pan-European e-government services (PEGS) across Member State (MS) borders. Improving interoperability in PEGS is expected to increase collaboration and efficiency across public administrations. Yet, a comprehensive approach to develop interoperable PEGS is still missing. Enterprise architecture (EA) is a concept used in the private sector to deal with organisational complexity, interoperability and the multifaceted challenges of information systems. We argue that EA can be used in a similar manner to foster interoperability in PEGS. This paper elicits requirements for constructing an EA framework for PEGS. The requirements are used to argue the suitability of existing EA frameworks and to propose areas of further research to build a customised architecture framework for ensuring interoperability in the design and implementation of PEGS.

**Keywords:** Interoperability, E-Government, Requirements, Architecture, Framework, Pan-European E-Government Services

## 1 Introduction

The European Commission refers to PEGS as a means to realize public service delivery across MS borders. PEGS are provided by different levels of public administration in the MS. They embark on modular, loosely coupled service components and infrastructure services [1].

Complexity, coordination and long term planning processes make it difficult for actors in e-government to create PEGS that are sustainable. Janssen et al. argue that organizations aiming to collaborate and work across institutional boundaries have to rethink and reshape existing strategies, structures, processes, infrastructures and business models. They claim that there is no consensus about the shape and elements of a government EA framework supporting the development of PEGS [2, 3].

An EA framework is used to develop an enterprise architecture (EA) [4]. An EA framework helps to establish customized conventions, principles and practices within an organization leading to shared perspectives regarding information and communication technology (ICT) related strategies, investments, designs and implementations [5]. The resulting EA helps decision makers to proactively and comprehensively identify and analyse the execution of changes towards a desired vision and outcomes [4].
An EA framework for PEGS should adopt a holistic view, where interoperability is examined beyond technical connectivity, that is, considering social, political, cultural and legal factors as well [2], [6], [7]. The holistic view on ICT provided by EA frameworks is seen as a vehicle and means to overcome interoperability challenges [2]. However, even though EAs are successfully used in the private sector, they are not yet appropriately adopted in government contexts [2], [6]. Successful EA adoption depends on appropriate institutional forces and transformation processes [3]. The use and effectiveness of EA is determined by the acceptance, coherence and governance of the architecture approach within the organizational context [8].

Hjort-Madsen and Pries-Heje argue that governmental EA is a means to improve efficiency of public services [3]. Governmental EAs are based on different frameworks which vary in scope and specialization [4], [9, 10, 11, 12, 13, 14]. A governmental EA may refer to an organization, it can emerge as a result of implementing individual projects or it may be directly specified on the basis of national/domain reference architectures. Thus, a governmental EA may relate to government as a whole, to a particular domain or to an organizational context. Hence, the abstract types of architectures provide plenty of guidance and references to generate more specific architectures [15]. Thus, EA can support governments to integrate relevant programs and projects and it provides elements such as standards, principles, technologies, services and building blocks [2].

To effectively support PEGS design and implementation, key components of governmental EA need to be identified and their relationships discussed. Current efforts in Europe are directed towards the establishment of a European Interoperability Reference Architecture (EIRA)<fnref n="1" /> and to initiate PEGS through a number of large-scale pilot projects (LSPs)<fnref n="2" />. LSPs run in different areas such as eHealth, eProcurement and eJustice. The e-SENS (Electronic Simple European Networked Services)<fnref n="3" /> project is an overarching LSP which creates a European Interoperability Architecture (EIA). E-SENS follows an architecture approach which is based on EIRA and other European interoperability policies. The major goal of e-SENS is to consolidate, improve, extend and sustain the results of previous LSP projects by identifying and sustaining building blocks (BB).

This paper aims to elicit architecture requirements that guide the construction of an EA framework for PEGS. The architecture requirements are derived from a systematic review of e-government and interoperability literature. The comparison of these requirements with established EA theories, concepts and frameworks helps to scope and to identify core components of an EA framework for PEGS. The analysis discloses gaps and determines areas of future research and therewith can be used to check the completeness of approaches like EIRA.

The paper is organised as follows: Section 2 provides an overview about research related to interoperability frameworks and EA frameworks. Section 3 introduces the research design for the subsequent requirements elicitation. Section 4 presents the architecture requirements guiding the examination of EA components. Major EA components along the architecture requirements are summarized in section 5. Section 6 investigates, which architecture requirements are fulfilled by existing EA frameworks

<footnote n="1">¹ EIRA: https://joinup.ec.europa.eu/node/99464</footnote>

<footnote n="2">² LSPs: https://ec.europa.eu/digital-agenda/en/large-scale-pilot-projects</footnote>

<footnote n="3">³ E-SENS: http://www.esens.eu/</footnote>
and the components they provide. The final section (7) concludes the work and discusses limitations and implications for further research.

## 2 Review of Interoperability Frameworks and EA Architectures

Since the publication of the European Interoperability Strategy (EIS) and European Interoperability Framework (EIF) in 2004, interoperability has been increasingly in focus of e-government [1]. The EIF has stimulated the adoption of government interoperability frameworks (GIF) in the different MS [16], [17]. GIFs are strategic by nature. They provide guidance on what to consider when establishing interactions among public administrations. The catalogue of policies, specifications, and standards provided by GIFs outlines a desired profile for e-government services [16], [18]. GIFs like the EIF emphasize on technical, semantic and organizational aspects of interoperability. However, they neglect methodological support for projects and initiatives [1], [19]. Due to missing methodological support, GIFs only provide a limited assistance to interoperability initiatives and projects [20].

Complementary to GIFs, EA frameworks offer assistance through methodological support in translating business visions and strategies into effective services [4]. EA frameworks provide a multidimensional approach [9], [16, 17, 18, 19]. They further detail the how, where, who, when and why next to the what which is addressed by GIFs [20]. EA frameworks can support a broader range of objectives and influence decision making on different levels. However, any EA adoption depends on an architectural governance process. A governance-centric approach ensures long-term sustainability and stakeholder acceptance [2], [7], [19], [21]. EA needs to respond to social interdependencies [15]. Thus, EA can be a successful tool, but it has to be adjusted to the strategic, social and technological context in which the architecture is embedded [22].

Before adopting an EA framework in a given context, the varying goals of EA frameworks are assessed: The Zachman framework is an analytical EA framework, which is used to describe ICT from different perspectives while lacking details on the design methods. Hence, it provides less support to adopters [9]. The Open Group's Architecture Framework (TOGAF) is a sophisticated architecture framework with a very detailed level of organizational support. Due to its large scope, TOGAF requires serious customization before being applied [10]. FEAF (Federal Enterprise Architecture Framework) may fit better with the idea of PEGS because it aims to improve interoperability among federal government agencies in the United States. However, the scope of FEAF is larger than the objective of PEGS because it promotes effective IT investment processes and consistent architectures among federal agencies [11], [23]. EAP (Enterprise Architecture Planning) and EITA (Enterprise IT Architecture) are planning oriented EA frameworks. They follow a pragmatic approach and structure. While EAP provides a set of well-defined steps to support the establishment, implementation, and ongoing maintenance of an EA program [14], EITA aims to handle, manage and integrate multiple systems [4], [12], [13]. Even though none of these EA frameworks perfectly fits the demands of PEGS, each one may contribute to interoperability needs.

Interoperability needs are captured by the European interoperability policy, which is realized by a series of initiatives and instruments. The strategic alignment of an EA
framework for PEGS can be ensured by integrating previous achievements of the Eu-
ropean interoperability policy [1], [18], [20], [24], [25]. The European interoperability
policy helps to reach a consensus, to identify interoperability needs and to promote
cross-border developments. It is structured into four phases: The first phase (awareness
building) relates to the establishment of the EIS and the EIF. The EIS and EIF provide
guidance for the creation of EIRA in phase two (establishment). The third phase (oper-
ation) initiates the use of this EIRA in different domains. Phase four (value adding)
uses established domain architectures to improve the value of public services [1], [18],
[20], [25]. Since approx. a decade, the European interoperability policy and the transi-
tion from GIFs to governmental EAs has been analysed in literature. Ray et al. compare
various GIFs along the analytical dimensions context, content and process, and present
a set of recommendations for new interoperability initiatives [17]. Charalabidis et al.
compare GIFs and architectures in different countries in order to indicate the similari-
ties and differences and to provide recommendations for the advancement of GIFs [16].
Guijarro investigates GIFs and EAs in Europe and the United States with a view on the
methodological support of these frameworks and derive a two-phased interoperability
roadmap consisting of an enabling phase and an alignment phase [18]. Götze et al. as-
sess national EA programs and show how these programs serve as precursors for cross-
border collaborations. The analysis points to major obstacles and drivers for cross-border
collaborations [20]. Kubicek et al. review important GIFs, develop a four-layer
framework and provide guidance for their re-conceptualization [27]. The findings of
these reviews strongly contribute to the identification of requirements for an EA frame-
work for PEGS, which is the main objective of this paper.

3 Research Design

This paper is part of a larger research effort which follows a qualitative approach using
exploratory research for theory development. Design science research is used to derive
the EA framework for PEGS. The architecture requirements presented in this paper
provide a ground to that research effort by synthesizing and integrating research in the
fields of e-government, EA and information systems. They are used to develop and
justify theories that explain how EA frameworks can be used to overcome interopera-
bility challenges. In IS research, design science is concerned with the design, specifi-
cation and evaluation of design products. By choosing design-science research, the
overall research methodology follows a proactive approach. The danger of design sci-
ence research is a missing theory base, which results in well-designed but useless arte-
facts. Hence, requirements analysis is used to overcome this limitation. The require-
ments express a need for design products, which is derived from an extensive literature
review in the fields of interoperability and EA research [28].

In order to propose sufficient design products or components of an EA framework
for PEGS, it is required to generate a problem space and to incorporate a search process
to detect appropriate solutions. The architecture requirements scope the problem space,
in which the envisioned EA framework shall operate. Hence, these requirements also
guide the search process by providing a set of defined criteria to determine, assess and
customize appropriate EA components. The identified EA components are thoroughly
evaluated by conducting literature reviews in the fields of EA research, EA standards
and EA frameworks. The analysis is carried out in three steps: A static analysis helps to examine the structure of EA components and their qualities. The fit of EA components is studied during the architecture analysis. Finally, the optimal properties of EA components are elaborated during an optimization process [28].

The hypothesis for the review of EA framework components against the architecture requirements for PEGS is as follows: While some PEGS architecture requirements are adequately addressed by one or more EA framework components, other architecture requirements are not or only partially addressed. Differences between requirements and EA components are defined as a gap. The identified gaps are further consolidated and structured into areas of further research. All results are linked to an analytical structure in order to construct a taxonomy, which is divided into three organizing themes: *context*, *contents* and *processes*, a typical approach of system analysis [17], [29]. The organizing themes enrich the qualitative research design and support the study of the socio-technical phenomena of the EA framework for PEGS [30].

# 4 Requirements of an EA framework for PEGS

The literature review in the field of governmental interoperability brought forward thirty architecture requirements. The requirements have been structured into the following six categories: project management (PM), stakeholder management (ST), service development (SD), interoperability layers and architecture viewpoints (LV), building blocks (BB), and collaboration agreements (CA). The categories are used to arrange the requirements in section 4. Existing EA components are assessed in section 5 against the fulfilment of these requirements. The requirement indications in the running text provide a unique numbering reference to each of the requirements.

## 4.1 Requirements related to the management of interoperability projects (PM)

E-government interoperability cannot be achieved by focusing on technical issues alone [16, 17, 18]. Nevertheless, it is important to share a common framework of technical standards, to follow general technological paradigms and to make use of best practice guidelines PM03 [16]. An EA framework for PEGS should adopt and promote high-level policies on interoperability [17]. It should provide means to ensure sufficient top-level management and political support, which is a critical factor when realizing cross-national collaborations PM05 [20]. Interoperability projects need to manage complexity and risks. They need to put attention to variables and factors beyond the technological view, such as availability of resources, legal and jurisdictional constraints, information security, governmental incentives, market forces, knowledge etc. PM04 [31].

Strategies to achieve interoperability do not automatically transform to the operational level. While top-down approaches often result in reduced legitimacy and acceptance of the planned collaboration solution, bottom-up approaches often result in technology-driven approaches. When realizing PEGS, contextual strategies may be better than control-seeking strategies. They are useful to address a critical thread on the path to interoperability, enabling a top-down approach PM01 without losing the link between the strategic and the operational level PM02 [16], [20], [22].
## 4.2 Requirements related to the management of stakeholders (ST)

The EA framework for PEGS has to ensure appropriate management and governance of stakeholders and their concerns ST01 including cross-organizational relationships ST02 [15]. Janssen et al. as well as Flak and Rose note that techniques that describe how to practically specify, implement and govern relationships and the information exchange between different actors and their IT systems are missing ST03 [2], [21].

## 4.3 Requirements related to service development (SD)

Interoperability should help to realize business transformation and service innovation processes by combining infrastructures services, business services, people and work processes SD03 [1]. Several authors mention that it is important to encourage openness, to follow business-driven needs SD01 and to rethink organizations and processes SD02 in order to enable business transformation processes and change of infrastructure and business (models) SD04 [1], [2], [16]. Service development should rather concentrate on business-driven needs than to lay its focus on technology or advancement-driven opportunities SD01 [16], [22]. Business requirements identify the scope of reform and help to find commonalities among agencies [17]. Implementations may be realized in several ways because interoperability shall encourage openness and a variety of solutions in the software industry SD05 [1].

## 4.4 Requirements related to interoperability layers and architecture viewpoints (LV)

While EA frameworks provide detailed guidelines on how to use EA viewpoints, interoperability frameworks classify system concerns using interoperability layers. Thus, an EA framework for PEGS should provide guidance on how to use the interoperability layers systematically LV03 [20]. While the EIF focuses on semantic interoperability as a means to inter-link different systems, EA frameworks emphasize on application viewpoints and application integration as a means to achieve interoperability. Following EIF recommendations, EA frameworks for PEGS should emphasize on common organizational and semantic specifications LV02 [1], [16, 17, 18].

The EA framework for PEGS should make clear how to use interoperability layers and architecture viewpoints to address different stakeholder needs and views LV04 [17], [20], [22]. Layers and viewpoints support the analysis of business related concepts as well as the alignment of IT systems and collaboration towards a shared vision [17], [20]. Thus, interoperability layers and architecture viewpoints follow a similar approach with different intentions. A link between them should be provided LV01.

## 4.5 Requirements related to the management of building blocks (BB)

The EIF emphasizes on service orientation, a component-based service model and the reusability of BBs BB01. An EA framework for PEGS should provide guidance on how to create BBs and how to enable a systematic (de)composition BB03 [1], [22]. Aggregate public services are typically constructed by grouping several service components into a coherent whole BB02 [1], [22]. The management of architecture and solutions
BBs is a critical threat for interoperability projects. Interoperability projects need to
embrace existing artefacts and repositories should provide access to them BB05. Ar-
chitecture guidelines should offer the necessary guidance on how to assemble and im-
plement aggregate public services BB04 [17], [22]. The integrated use of repositories
in combination with adequate modelling tools and collaboration tools has the potential
to increase the provision, acceptance and adoption of BBs BB06 [16].

4.6 Requirements related to the provision of collaboration agreements (CA)

Collaboration agreements ensure a successful interaction and are preferred means to
achieve interoperability [1], [6]. Interoperability requires the publication of agreements
(methods, specifications, standards) that describe the ways of interoperation CA02 [6].
Collaboration agreements are often restricted to the syntactical level of the data ex-
change. An EA framework for PEGS should provide guidelines, rules and principles
that show how to use them on a semantic and organisational level CA 03[2].

There are problems related to the uptake of collaboration agreements, their evolu-
tion and how to ensure trust across multiple organizations. Life-cycle management of
collaboration agreements can be used to improve governance and compliance mecha-
nism. Collaboration agreements have to be suitable for designing and standardizing the
next generation of interfaces CA05 [17], [22]. Next to a good cooperation ability [17],
it is important to share principles for service development such as scalability, reusabil-
ity, flexibility, preference for open standards, preference for open standards and secu-
rit y in order to establish trust among organizations CA01 [16]. Maturity levels and
compliance levels should be used to measure the compliance of specifications and im-
plementations with the defined principles and business requirements CA06. Thus, a
methodology to assess and select technologies, standards and implementations (e.g.
quality measurement, conformance testing, requirements based incorporation/with-
d withdrawal of standards etc.) should be considered CA04 [16], [20].

5 EA components addressing the architecture requirements

The previous section outlined 30 architecture requirements of an EA framework for
PEGS. In this section, important EA components and their capabilities are studied and
assessed in regards to whether they fulfil the identified architecture requirements. The
analysis is structured along the three organizing (cf. section 3). A requirement may be
linked to one or more EA components. The relationship is described through two types
of indicators: A requirement ID is indicated as resolved with the indicator RES (14 re-
quirements, cf. Fehler! Verweisquelle konnte nicht gefunden werden. in section
5.4); the indicator OPN points to a contribution of an EA component to resolve a require-
ment, while the requirement itself remains open for further research (16 requirements).
The 16 open requirements are consolidated into areas of future research in the conclud-
ing section 6.
## 5.1 Contextual EA components

The use of baseline architecture and target architecture in EA frameworks provides a basis for increasing maturity and enabling business standardization over time $^{OPN-CA06}$ [8], [10], [11]. Levels of architecture scope (e.g. national, sector, local) describe the types of organizational complexity, which are addressed by an EA. They promote comparability and consistent use of architecture outputs for certain usage levels [11]. According to the EIF, European-wide and sector-specific architecture solutions are the envisioned levels of scope for PEGS $^{OPN-PM04}$ [1]. The concept of primary outcomes represents areas of an EA framework where a direct, positive impact can be made [11]. The primary outcomes of an EA framework for PEGS are service delivery, cooperation, information exchange, sharing and reuse and reduction of costs [1]. A defined set of primary outcomes offers principle guidance when developing PEGS $^{OPN-BB03}$.

EA frameworks comprise basic elements such as principles, methods, tools and standards [10], [11], [32]. Basic elements ensure that EA programs and EA projects are complete and effective in developing service components and building blocks $^{OPN-PM04}$. They can be used as a basis for projects to define a project-specific architecture approach, to establish a standards framework and technological paradigm and to adopt best practice guidelines $^{RES-PM03}$ [11], [32].

Architecture documentation shall be created along a set of core artefacts. The TOGAF content framework determines various types of analysis, modelling techniques and artefacts for each architecture viewpoint $^{OPN-LV03}$. It structures architectural contents and clarifies the relationships between building blocks, artefacts and deliverables and therewith provides guidance for the composition of aggregate public services. The TOGAF enterprise continuum operates on a higher level of abstraction. It clarifies how foundation architectures, reusable service components and building blocks can be adapted to certain contexts in order to create specific architectures and solutions. Both, TOGAF Enterprise Continuum and the TOGAF content framework provide a powerful way for allocating, classifying and combining artefacts on various levels $^{RES-BB04}$ [10].

Architecture meta-models clarify various EA concerns. While the Zachman framework puts forward different perspectives on information systems, enterprise analysis and modelling [9], ISO/IEC/IEEE std. 42010:2011 addresses the management of architectures through the use of architecture descriptions. The ISO/IEC/IEEE meta-model is a generic approach related to the creation of architecture descriptions $^{RES-BB05}$. It separates between architecture viewpoints and views $^{OPN-LV04}$ enabling partitioning of system concerns according to stakeholder needs $^{OPN-ST01}$ [33]. The definition of model fragments along architecture viewpoints supports the process to create architecture models and BBs. Pattern-based approaches are helpful when aiming to create reusable, modular and loosely coupled service components and building blocks $^{OPN-BB01}$ [34].

## 5.2 Content-related EA components

Architecture viewpoints offer the possibility to follow a top-down approach by providing links between business and technical viewpoints. This approach increases legitimacy and acceptance of outputs. The use of a strategy viewpoint in an EA viewpoint model helps to find a common agreement upon the desired outputs. The strategy viewpoint drives the developments done along other architecture viewpoints $^{RES-PM01}$ [5].
Links to the operational level can be best established through requirements management, a central activity of the EA life-cycle (cf. section 5.3) <sup>OPN-SD01</sup> [10].

EA viewpoints can be easily mapped to interoperability layers as shown in [20] RES-LV01. A reorganization process leads to changed foci of architecture development. Less emphasis is put on intentions related to an application architecture, while more emphasis is put on semantic, organizational and legal interoperability layers by integrating them into the information architecture, business architecture and strategy viewpoint RES-LV02. The understanding and scope of architecture viewpoints may vary from one community to another. ArchiMate is an architecture description language which aims to systemize the creation of architecture models along architecture viewpoints. Thereby, ArchiMate offers the possibility to separate between the different service concerns imposed by an architecture RES-BB02. The separation allows for example to change a business service without affecting the services defined on the technical or infrastructure level RES-SD04. ArchiMate also specifies model fragments for each architecture viewpoint. It therewith provides guidance on the systematic use of architecture viewpoints OPN-LV03. The use of ArchiMate therewith offers the possibility to provide a consistent way to describe business processes, organizational structures, information flows, IT systems, and technical infrastructures RES-BB06 [35], [36].

## 5.3 Process-related EA components

EA life-cycle models (LCM) define a number of activities to enable structured, comprehensive and systematic architecture development. The phases identified by major EA frameworks (cf. section 2) are the analysis phase, the design phase, the transition and the implementation phase. We propose an adaptation of TOGAF's Architecture Development Method (ADM).

The EA LCM distinguishes between six sequential (A-F) and six central (G-L) phases.

By combining sequential and central phases, top-down processing of architecture issues is ensured RES-PM02. The proposed EA life-cycle model for PEGS adopts the structure of TOGAF architecture development method and integrates components from other EA life-cycle models (Fig. 1). The first two phases, A. Planning & Initialization and B. Architecture Vision, are well documented by all frameworks. Thus, sufficient methodologies to adopt best practices, to define project architecture, standard framework and technological paradigm are offered RES-PM03. The next two phases aim to define C. Baseline Architecture and D. Target Architecture (cf. section 5.1) using the different architecture viewpoints as an underlying structure (cf. section 5.2). The distinction between baseline and target helps to systematically develop issues related to the information system exchange OPN-

ST03 [10], [12], [14]. The phases E. Architecture Transition and F. Architecture Governance realize business transformation and change processes through iterative planning. Detailed guidelines for architecture transition and architecture governance are provided by many EA frameworks (e.g. TOGAF guideline on Business Transformation & Readiness Assessment) OPN-SD03 [10], [13], [14].

<figure><img src="image_2.png" /><figcaption>Fig. 1. EA LCM for PEGS adapted from [10]</figcaption></figure>
The central phase *J. Requirements Management* enables the alignment of architecture outputs with business-driven needs. Requirements driven approach is used to increase legitimacy and acceptance of outputs <sup>OPN-SD 01</sup> [10]. The TOGAF guideline for Business Scenarios helps to elicit business requirements and business goals <sup>OPN-SD01</sup>. Acceptance of outputs is controlled via *G. Stakeholder Management* phase, which offers the possibility to establish collaboration agreements on the basis of formalized stakeholder approval and change processes <sup>RES-CA02</sup>. TOGAF deliverables like stakeholder contract, change request, request for architecture work are supportive to many types of stakeholder concerns. The TOGAF guideline on Interoperability Requirements offers a means to formalize cross-organizational relationships <sup>RES-ST02</sup>. Stakeholder Management ensures the safeguarding of stakeholder support, a critical threat in many interoperability projects. TOGAF provides a detailed guideline and various techniques for Stakeholder Management <sup>RES-PM05</sup> [10], [12]. Requirements driven selection of standards and technology is part of the phase *I. Standards & Technology Management*. The phase ensures adequate management of specifications and technologies in order to establish, select and validate adequate architecture foundations according to a technology strategy [10], [12]. Maturity models and levels help to measure the state of technology and help to visualize how standards and technologies pass through stages (e.g. trial, active, phasing out) <sup>RES-CA05</sup> [10], [12]. Phase *L. Repository Management* acknowledges the need for managing artefacts across the architecture landscape. The TOGAF approach to Repository Management provides a mature repository structure which helps to organize, access and manage different outputs <sup>RES-BB05</sup> [10], [14]. The phases *H. Risk Management* and *K. Project Management* acknowledge risks and complexities accompanied with interoperability projects and efforts. TOGAF and other EA frameworks provide guidelines on Risk Management, which include methodologies for risk mitigation <sup>OPN-PM04</sup> [10], [12], [14].

## 5.4 Fulfilment of requirements through EA components

In the previous sub-sections, several EA components were identified, examined and re-arranged. Table 1 shows how the architecture requirements identified in section 4 are resolved through above EA components. Major contextual EA components are the levels of architecture scope, primary outcomes and basic elements of an architecture framework. Architecture principles provide a ground and can be used to guide system development and identify directions to be taken in interoperability programs and projects. EA frameworks distinguish between baseline and target architecture in order to reach a desired vision and to identify necessary modifications. Architecture outputs can be systemized using std. 42010:2011 [33], TOGAF content framework or TOGAF enterprise continuum [10].

EA viewpoint components describe architecture contents that range from strategic to technical concepts. EA viewpoints which are harmonized with interoperability layers build a cornerstone of an EA framework for PEGS. Each architecture viewpoint can be described through a range of model fragments and techniques that support the development of architecture content. The use of an architecture description language helps to systemize the model fragment use [36].
EA life cycle components describe how an EA evolves over time (i.e. the development process). EA management is an important function. It describes how EA is established and it addresses the management of contents, technologies, standards, requirements, stakeholders, complexities and risks. The phased approach of architecture development integrates the architecture viewpoints and shows how architecture transition and architecture governance is executed.

<table><caption>**Table 1.** Fulfilment of architecture requirements through EA components</caption><thead><tr><th>ARE A</th><th>EA COMPONENT DESCRIPTION</th><th>NR</th></tr></thead><tbody><tr><td rowspan="4">Contextual EA components</td><td>Primary outcomes, levels of scope and basic elements (principles, methods, tools, patterns and standards) ensure that EA programs are complete and effective.</td><td>PM03</td></tr><tr><td>TOGAF Deliverables: Stakeholder Contract, Change Request, Request for Architecture Work and Communication Plan.</td><td>ST02</td></tr><tr><td>TOGAF content framework structures architectural content and shows how to compose aggregate public services. TOGAF enterprise continuum provides method how to adapt architectures and solutions to certain contexts</td><td>BB04</td></tr><tr><td>ISO/IEC/IEEE std. 42010: 2011 clarifies how to create, analyse & sustain architectures using architecture descriptions</td><td>BB05</td></tr><tr><td rowspan="6">EA content components (viewpoints)</td><td>Use of strategy viewpoint to drive architecture development</td><td>PM01</td></tr><tr><td>Inclusion of strategy viewpoint.</td><td>PM02</td></tr><tr><td>ArchiMate distinguishes between different types of services. Each service type can be defined and changed independently.</td><td>SD04<br>BB02</td></tr><tr><td>Establishment of links between interoperability layers and architecture viewpoints.</td><td>LV01</td></tr><tr><td>Integrating semantic, organizational and legal aspects of interoperability layers into the information architecture, business architecture and strategy viewpoint.</td><td>LV02</td></tr><tr><td>ArchiMate models provide capabilities to collaborate and agree on service components.</td><td>BB06</td></tr><tr><td rowspan="8">EA process components (life-cycle)</td><td>Sequential phases of ADM ensure top-down processing.</td><td>PM01</td></tr><tr><td>Combination of sequential and central phases. Requirements Management provides bridge between strategy and operation.</td><td>PM02</td></tr><tr><td>Planning & Initialization and Architecture Vision phase clarify how to initialize interoperability projects</td><td>PM03</td></tr><tr><td>Stakeholder Management phase and TOGAF guideline and techniques on Stakeholder Management help to manage various concerns.</td><td>PM05</td></tr><tr><td>TOGAF guideline on Interoperability Requirements can be used to visualize cross-organizational relationships.</td><td>ST02</td></tr><tr><td>Repository Management Phase and TOGAF Architecture Repository help to organize architectures outcomes.</td><td>BB05</td></tr><tr><td>Stakeholder Management phase offers possibility to introduce formalized stakeholder approval and change processes.</td><td>CA02</td></tr><tr><td>Standard & Technology Management phase clarifies when to establish, select and validate standards and technologies and how to use them as architecture foundations.</td><td>CA05</td></tr></tbody></table>

The architecture requirements, which are declared to be open, are structured into areas of further research in the concluding section.
# 6 Conclusions

An efficient EA framework for the design, implementation and maintenance of interoperable PEGS should combine generic EA components with concepts, methods and solutions from e-government and interoperability research. In this contribution, we investigated requirements for the design and implementation of interoperable PEGS and we studied how well these architecture requirements are already fulfilled by existing EA frameworks and components. The study has certain limitations. The completeness of the architecture requirements was not approved in a separate process and only five EA frameworks and one standard were investigated (beside important contributions in EA research and practice). The measurement of fulfilment did not follow a formal evaluation process but relied on reviews carried out by the authors. This may result in a limited traceability of results.

We conclude that EA is a helpful means to realize interoperable PEGS. The investigation has shown that approx. half of the 30 architecture requirements identified throughout the study are adequately addressed by existing EA frameworks and EA components. However, not all architecture requirements identified throughout this paper are successfully implemented in existing EA frameworks or they are only partially addressed. These issues point to areas of further research, summarized in the following ten research needs, which are stated per analytical dimension (cf. section 3).

The contextual design of an EA framework for PEGS can be strengthened by integrating a number of aspects. There are many common interoperability challenges when establishing PEGS. (1) Critical success factors to overcome these challenges should be identified and integrated in order to provide a general guidance for interoperability projects. (2) An EA framework for PEGS should be built upon widely accepted principles and strategies (e.g. outlined by the EIF and EIS). Additionally it should (3) comprise architecture design principles and guidelines to reason about alternative design strategies. In order to facilitate stakeholder management, an EA framework for PEGS should (4) refer to abstract stakeholder classes and roles in interoperability projects and determine drivers for their engagement.

The creation of contents within an EA framework for PEGS can be improved through the following aspects and methods: (5) Development of a requirements management methodology that supports the capturing of requirements from business-driven needs, policy implementation processes and other strategic aspects in order to establish common path and to increase the acceptance of architecture outputs among stakeholders. (6) Another methodology should describe how to define interoperability specifications on semantic and organizational level, which can be used as a basis for collaboration agreements. (7) A detailed design of each architecture viewpoint should be outlined. Such detailed design should identify relevant model fragments and should be based on a commonly agreed architecture description language [36].

The processes of architecture development can be improved as follows: (8) There are missing guidelines and methods that describe how to transition and to govern architectures in multi-stakeholder environments. Several independent implementations of PEGS have to be coordinated, extended and sustained over time. (9) An EA framework for PEGS should integrate appropriate assessment methodologies that can be used at different phases of architecture development. Assessment methodologies can be used to measure the current state of specifications and the compliance of solutions with the
underlying collaboration agreements. (10) Other assessment methodologies can help to determine the level of business standardizations in a domain and to appraise the maturity of market solutions in order to detect appropriate ways forward.

The ten research needs identified before are subject of ongoing investigations towards the development of a comprehensive EA framework for PEGS.

## References

1. European Commission, "European Interoperability Framework (EIF) for European public services," *COM(2010) 744 final*, European Commission, Brussels, p. 40, 2010.

2. M. Janssen, Y. Charalabibis, G. Kuk, and T. Cresswell, "Guest Editors' Introduction: E-government Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges," *J. Theor. Appl. Electron. Commer. Res.*, vol. 6, no. 1, pp. I-VIII, Apr. 2011.

3. K. Hjort-Madsen and J. Pries-Heje, "Enterprise Architecture in Government: Fad or Future?," *42nd Hawaii International Conference on System Sciences (HICSS-42)*. Waikoloa, Big Island, Hawaii, p. 132 (1-10), 2009.

4. F. J. Armour, S. H. Kaisler, and S. Y. Liu, "A big-picture look at enterprise architectures," *IEEE IT Prof.*, vol. 1, no. 1, pp. pp. 35-42, 1999.

5. R. Winter and R. Fischer, "Article Essential Layers, Artifacts, and Dependencies of Enterprise Architecture," *J. Enterp. Archit.*, no. May, pp. 1-12, 2007.

6. H. J. Scholl and R. Klischewski, "E-Government Integration and Interoperability: Framing the Research Agenda," *Int. J. Public Adm.*, vol. 30, no. 8-9, pp. 889-920, Jul. 2007.

7. H. J. Scholl, H. Kubicek, and R. Cimander, "Interoperability, Enterprise Architectures, and IT Governance in Government," in *Electronic Government*, vol. 6846, M. Janssen, H. J. Scholl, M. A. Wimmer, and Y. Tan, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 345-354.

8. M. Janssen, "Framing Enterprise Architecture: A Meta-Framework for Analyzing Architectural Efforts in Organizations," in *Coherency Management—Architecting the Enterprise for Alignment, Agility and Assurance*, G. Doucet, J. Götze, P. Saha, and S. Bernard, Eds. Bloomington: AuthorHouse, 2009, pp. 99-119.

9. J. A. Zachman, "A framework for information systems architecture," *IBM Syst. J.*, vol. 26, no. 3, pp. 276-292, 1987.

10. The Open Group, "TOGAF Version 9.1," 2011. [Online]. Available: http://pubs.opengroup.org/architecture/togaf9-doc/arch/. [Accessed: 30-Mar-2015].

11. US Office of Management & Budget, "Federal Enterprise Architecture Framework - Version 2." The White House, pp. 1-434, 2013.

12. F. J. Armour, S. H. Kaisler, and S. Y. Liu, "Building an Enterprise Architecture Step by Step," *IEEE IT Prof.*, vol. 1, no. 4, pp. 31-39, 1999.

13. F. J. Armour and S. H. Kaisler, "Enterprise architecture: agile transition and implementation," *IT Prof.*, vol. 3, no. 6, pp. 30-37, 2001.

14. S. Spewak and M. Tiemann, "Updating the Enterprise Architecture Planning Model," *J. Enterp. Archit.*, vol. 2, no. May, pp. 11-19, 2006.

15. M. Janssen, "Sociopolitical Aspects of Interoperability and Enterprise Architecture in E-Government," *Soc. Sci. Comput. Rev.*, vol. 30, no. 1, pp. 24-36, Jan. 2012.

16. Y. Charalabidis, F. Lampathaki, and D. Askounis, "A Comparative Analysis of National Interoperability Frameworks," *15th Americas Conference on Information Systems (AMCIS 2009)*, vol. Paper 694. AIS, San Francisco, CA, pp. 1-10, 2009.
17. D. Ray, U. Gulla, S. S. Dash, and M. P. Gupta, "A critical survey of selected government interoperability frameworks," *Transform. Gov. People, Process Policy*, vol. 5, no. 2, pp. 114-142, 2011.

18. L. Guijarro, "Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States," *Gov. Inf. Q.*, vol. 24, no. 1, pp. 89-101, 2007.

19. H. Kubicek and R. Cimander, "Three dimensions of organizational interoperability: Insights from recent studies for improving interoperability frameworks," *Eur. J. ePractice*, no. 6, pp. 3-14, 2009.

20. J. Gøtze, P. E. Christiansen, R. K. Mortensen, and S. Paszkowski, "Cross-National Interoperability and Enterprise Architecture," *Informatica*, vol. 20, no. 3, pp. 369-396, 2009.

21. L. S. Flak and J. Rose, "Stakeholder Governance: Adapting Stakeholder Theory to E-Government," *Commun. Assoc. Inf. Syst.*, vol. 16, pp. 642-664, 2005.

22. R. Klischewski, "Architectures for tinkering? Contextual strategies towards interoperability in E-government," *J. Theor. Appl. Electron. Commer. Res.*, vol. 6, no. 1, pp. 26-42, 2011.

23. US Office of Management and Budget, "The Common Approach to Federal Enterprise Architecture," *Office of Management and Budget*. The White House, p. 52, 2012.

24. European Commission, "European Interoperability Strategy (EIS) for European public services." European Commission, Brussels, pp. 1-8, 2010.

25. J. I. Criado, "Interoperability of eGovernment for Building Intergovernmental Integration in the European Union," *Soc. Sci. Comput. Rev.*, vol. 30, no. 1, pp. 37-60, 2012.

26. Y. Charalabidis, F. Lampathaki, A. Kavalaki, and D. Askounis, "A review of electronic government interoperability frameworks: patterns and challenges," *Int. J. Electron. Gov.*, vol. 3, pp. 189-221, 2010.

27. H. Kubicek, R. Cimander, and H. J. Scholl, *Organizational Interoperability in E-Government - Lessons from 77 European Good-Practice Cases*. Springer Berlin / Heidelberg, 2011.

28. A. R. Hevner, S. T. March, J. Park, and S. Ram, "Design Science in Information Systems Research," *MIS Q.*, vol. 28, no. 1, pp. 75-105, 2004.

29. J. Attride-Stirling, "Thematic networks: an analytic tool for qualitative research," *Qual. Res.*, vol. 1, no. 3, pp. 385-405, 2001.

30. K. Hjort-Madsen, "Enterprise Architecture Implementation and Management: A Case Study on Interoperability," *39th Hawaii International Conference on System Sciences (HICSS-39)*. Computer Society Press, Kauai, p. 71c (1-10), 2006.

31. E. M. dos Santos and N. Reinhard, "Barriers to Government Interoperability Frameworks Adoption," in *16th Americas Conference on Information Systems (AMCIS 2010)*, 2010, pp. 1-10.

32. M. Janssen, L. S. Flak, and Ø. Sæbø, "Government Architecture: Concepts, Use and Impact," in *Electronic Government*, M. A. Wimmer, M. Janssen, and H. J. Scholl, Eds. Springer Berlin Heidelberg, 2013, pp. 135-147.

33. ISO/IEC/IEEE, "Systems and software engineering - Architecture Description (ISO/IEC/IEEE 42010)," vol. 2011. ISO/IEC/IEEE, p. 46, 2011.

34. S. Buckl, A. M. Ernst, J. Lankes, F. Matthes, and C. M. Schweda, "Enterprise Architecture Management Patterns - Exemplifying the Approach," in *12th International IEEE Enterprise Distributed Object Computing Conference, 2008. (EDOC '08)*, 2008, pp. 393-402.

35. M. M. Lankhorst, H. a Proper, and H. Jonkers, "The Architecture of the ArchiMate Language," in *Enterprise, Business-Process and Information Systems Modeling*, vol. 29, Springer, 2009, pp. 367-380.

36. The Open Group, "ArchiMate 2.1 Specification." The Open Group, Berkshire, p. 181, 2013.