Keywords

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–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)Footnote 1 and to initiate PEGS through a number of large-scale pilot projects (LSPs)Footnote 2. LSPs run in different areas such as eHealth, eProcurement and eJustice. The e-SENS (Electronic Simple European Networked Services)Footnote 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: Sect. 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 Sect. 5. Section 6 investigates, which architecture requirements are fulfilled by existing EA frameworks 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–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 European 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 (operation) 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 transition 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 similarities 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. assess 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 [26]. The findings of these reviews strongly contribute to the identification of requirements for an EA framework 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 interoperability challenges. In IS research, design science is concerned with the design, specification and evaluation of design products. By choosing design-science research, the overall research methodology follows a proactive approach. The danger of design science research is a missing theory base, which results in well-designed but useless artefacts. Hence, requirements analysis is used to overcome this limitation. The requirements express a need for design products, which is derived from an extensive literature review in the fields of interoperability and EA research [27].

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 [27].

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, 28]. The organizing themes enrich the qualitative research design and support the study of the socio-technical phenomena of the EA framework for PEGS [29].

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 Sect. 4. Existing EA components are assessed in Sect. 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–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 [30].

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–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. Architecture guidelines should offer the necessary guidance on how to assemble and implement 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 exchange. 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 evolution and how to ensure trust across multiple organizations. Life-cycle management of collaboration agreements can be used to improve governance and compliance mechanism. 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, reusability, flexibility, preference for open standards, preference for open standards and security in order to establish trust among organizations CA01 [16]. Maturity levels and compliance levels should be used to measure the compliance of specifications and implementations 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/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. Sect. 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 requirements, cf. Table 1 in Sect. 5.4); the indicator OPN points to a contribution of an EA component to resolve a requirement, while the requirement itself remains open for further research (16 requirements). The 16 open requirements are consolidated into areas of future research in the concluding Sect. 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, 31]. 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, 31].

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 [32]. 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 [33].

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. Sect. 5.3) OPN-SD01 [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 [34, 35].

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. Sect. 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-PM 02. 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. Sect. 5.1) using the different architecture viewpoints as an underlying structure (cf. Sect. 5.2). The distinction between baseline and target helps to systematically develop issues related to the information system exchange OPN-ST 03 [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].

Fig. 1.
figure 1

EA LCM for PEGS adapted from [10]

Full size image

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 OPN-SD 01 [10]. The TOGAF guideline for Business Scenarios helps to elicit business requirements and business goals OPN-SD01. 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 RES-CA02. 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 RES-ST02. 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 RES-PM05 [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) RES-CA05 [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 RES-BB05 [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 OPN-PM04 [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 Sect. 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 [32], TOGAF content framework or TOGAF enterprise continuum [10].

Table 1. Fulfilment of architecture requirements through EA components
Full size table

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 [35].

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.

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. Sect. 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 [35].

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.