Pedro Rui

Lourenço

Open Government policies: untangling the differences and similarities between the US and the EU approach

Keywords: Open government, policy, assessment

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In 2003 the OECD published a report entitled "Open Government: fostering dialogue with civil society" [START_REF]Open Government[END_REF], based on a conference held in 2002. In this report, the concept of an 'open government' was still mainly related with policy-making openness, with an emphasis on information, consultation and public participation, the hallmarks of eDemocracy and eParticipation [START_REF] Oecd | Citizens as Partners -OECD Handbook on Information, Consultation and Public Participation in Policy-Making[END_REF]. Later on, Linders and Wilson [START_REF] Linders | What is Open Government? One Year after the Directive[END_REF] analyzed the United States (US) Memorandum on Transparency and Open Government [START_REF] Obama | Transparency and open government. Memorandum for the heads of executive departments and agencies[END_REF] and further confirmed that the main ideas and concepts behind it were not entirely new. In fact, they identified four main perspectives ("lenses") which influenced the Memorandum, namely with ideas from transparency advocates, technology savvies ("the futurists"), civil society eParticipation promoters, and bureaucrats worried about compliance to mandates and standards. Nevertheless, 2009 seems to be a landmark year as both the US and the EU launched their open government related policy framework. Despite the organizational differences between the two 'blocks', federal state (US) and country union (EU), they are both highly influential worldwide in what concerns eGovernment-related progress. Therefore it is appropriate and relevant to jointly analyze the process by which both 'blocks' have defined and are currently implementing their open government related policies.

However, at this point, it does not seem straightforward, from an ordinary citizen (someone not directly involved in the open government policy-formulation process as a public official) point of view, to fully understand the key concepts and supporting documents of both the US and the EU open government policy. The long list of EU reports at the end of this paper (references section), and the apparent proliferation of related websites, portals and dedicated webpages, for instance, illustrates this difficulty.

Therefore, the first objective of this paper is to untangle the open government policy framework in both 'blocks' (US and EU), and shed some light on it from an ordinary citizen point of view. For this purpose, an exploratory research effort was conducted based on content analyses of websites and key policy documents 1 . More specifically, the following issues were addressed:

 How easy is it to find information, and to navigate through the different official documents, in order to have a clear picture about US and EU open government policy?  What are the main distinctive characteristics between their open government policy, including concepts, development process, and assessment?  Overall, what can we learn from the way both policies were defined and implemented?

This work did not aim to provide definitive answers but the main finding from this exploratory research effort indicate that the option to define an autonomous open government policy by the US may have contributed to an increased simplicity, clearness and (external) visibility when compared with the EU choice to embed its open government policy on pre-existing eGovernment development. Ultimately, the EU approach may render it more difficult to an ordinary citizen to understand the policy, its implications and impact.

The remainder of this paper is structured around four specific perspectives from which both open government policy framework were analyzed, ending with an overall discussion and conclusions.

Finding information on open government policy

To start untangling the differences and similarities between the US and the EU approach we need to consider how easy it is to find relevant information concerning the open government policy in both cases. An ordinary citizen point of view was adopted that assumes such information should be available on the Internet, and that some initial reference (starting point) would exist in the White House and the European Commission homepages respectively.

2.1

The

US case

No direct reference to 'open government' was found in the White House homepage2 , including in the Initiatives section, so it was necessary to perform an internet search. Using the expression 'Open Government USA' on Google yielded an 'Open Government Initiative | The White House' link 3 , which pointed to the Open Government homepage. From this homepage, within different sections, it is possible to access:  A description of the general aspects related to the Open Government initiative, including a link to the Directive and Memorandum documents;  Direct links to some federal flagship initiatives on Transparency (such as data.gov, recovery.gov, USASpending.gov, IT.usaspending.gov, or foreignassistance.gov), Participation (such as 'We the People' or the 'Open Government Discussion Group') and Collaboration (such as 'Challenge.gov');  A link to "The Obama Administration's Commitment to Open Government Status

Report" [START_REF] House | The Obama Administration's Commitment to Open Government Status Report[END_REF];  Links to a dedicated 'Open Government Partnership' webpage 4 and external 'Open Government Partnership' website 5 . Also made available here is: ─ A list of all Open Government National Action Plans, developed in the 'Open Government Partnership' context, including a link to the US Third (latest) Open Government National Action Plan [START_REF] House | The Open Government Partnership: Third Open Government National Action Plan for the United States Of America[END_REF]; ─ The Open Government Partnership Government Self-assessment Report [START_REF] House | The Open Government Partnership: Government Self-Assessment Report for the United States Of America[END_REF] 6 ;  Information concerning the Interagency Open Government Working Group, with a specific webpage 7 which lists and links to each agency Open Government program specific homepage. Another memorandum [START_REF] House | Memorandum for the Heads of Executive Departments & Agencies[END_REF] is also available to "assist agencies as they prepare to launch their 2014 Open Government Plans".

The content and organization of this homepage not only reflects the major concepts of the US policy framework, but it also provides access in a single point to the most relevant initiatives and policy documents.

The EU case

There was also no direct reference on the European Commission homepage8 to 'Open Government'. As in the US case, it was necessary to perform an internet search to find the applicable information. Using the expression 'Open Government European Union' on Google yielded an 'Open government | Digital Agenda for Europe' 9 . The analysis of the webpage navigation path ('European Commission > Digital Agenda for Europe > Open government') reflects an 'Open government' topic under the more broad 'Digital Agenda for Europe' subject.

In the navigation bar, the topic 'Open Government' is presented in a hierarchical tree structure under 'Public Services' and 'Digital Society' (top level), alongside with 'Action plan 2011-2015', 'Cross-border solutions' and 'eGovernment studies'. Still in the navigation bar, three topics are grouped under 'Open Government', each one linking to specific webpages which detail its associated content: Within the webpage content it is also possible to find three external links:  'Open data' 10 , which links to a dedicated webpage and provides access to several legislative and non-legislative measures as well as a list of several Member State's and EU open data portals;  'ICT-enabled public sector innovation' 11 , which links to the same content as the 'Horizon2020' topic in the navigation bar;  'Vision for public services', which links to another webpage and a specific policy document [START_REF]A vision for public services[END_REF].

 'eParticipation',
This webpage is somewhat hidden within and alongside several other eGovernment thematic pages without a clear and direct relation to open government. The way the navigation path and navigation bar are structured further contribute to create a fuzzy image about the EU open government policy. The actual content of this webpage does generically refer to some of the same components and principles also present in the US Directive, such as transparency, citizen participation and engagement, and "collaboration for the design, production and delivery of public service". However, the emphasis seems to be on 'public service innovation' and general eGovernment development.

Initial landmark event information

Once an initial source of online information was found, the analysis proceeded to identify the initial landmark event which kick-started the open government policy.

The US case

In the US case, a detailed description of the initial policy documents (Directive and Memorandum) is clearly available, including the documents themselves, in the White House open government homepage.

Despite previous efforts to increase/adopt transparency, participation and collaboration principles in the US Administration, the Memorandum on Transparency and Open Government issued by President Obama in 2009 is considered the landmark event that initiated the systematic development of the US policy.

As a first consequence of the Obama Memorandum, Peter Orszag, Director of the Office of Management and Budget (OMB), issued an Open Government Directive [START_REF] Orszag | Open government directive. Memorandum for the Heads of Executive Departments and Agencies[END_REF]. The Directive 12 required "executive departments and agencies to take … steps toward the goal of creating a more open government" by publishing government information online and improving its quality, creating a policy framework and establishing a culture of open government.

The Directive also established several deadlines to implement specific actions ("Within 45 days, each agency, …") and guidelines on how these agencies should formulate and publish their individual plans, including the obligation to rely on "extensive public and employee engagement while formulating their open government plans. Apart from identifying the three original main areas covered by these plans, transparency, participation, and collaboration, federal agencies were also required to describe at least one "Flagship Initiative" in one of those areas.

In sum, it is easy to identify and access the initial US open government policy documents which, in turn, contain a clear and concise description of the main policy guidelines and implementation path.

3.2

The EU case Contrary to the US, in the EU case it is necessary to navigate through the 'ICT-enabled public sector innovation' link or the 'Horizon2020' topic in the navigation bar to access a description of its policy origin.

In a similar way to the US Directive, the Malmö Ministerial Conference on eGovernment, which also took place in 2009, seems to have provided the main initial political impulse to open government efforts in the EU. In fact, in the "ICT-enabled public sector innovation in Horizon 2020" webpage 13 there is a mention to the 2009 Malmö Ministerial Conference on eGovernment [START_REF]Ministerial Declaration on eGovernment[END_REF] as the moment when the vision to "make European public administrations open, flexible and collaborative in their relations with citizens and businesses" was laid out. According to the same webpage, this vision was afterwards translated "into several concrete actions through the open government concept, in the European eGovernment Action Plan 2011-2015" (this document was published in December 2010).

Although the Malmö Ministerial Conference Declaration does not specifically refer to 'open government' (there is no single mention of this particular term), it does refer generally to the need for "governments to be more open, flexible and collaborative in their delivery of public services".

The Declaration also addresses general concerns (such as reducing the carbon footprint) and traditional eGovernment themes such as the need to develop "user-centric services", "multi-channel strategies", and to "apply information and communication technologies in order to increase efficiency and effectiveness".

Additionally, the Declaration does refer to some specific open government related shared objectives and policy priorities such as transparency for accountability ("Strengthen transparency of administrative processes. … Transparency promotes accountability and trust in government"), transparency for data re-use ("Increase availability of public sector information for reuse. ... encourage the reuse of public data by third parties"), participation ("Involve stakeholders in public policy processes. … effective, useful and better ways for businesses and citizens to participate in the policy processes") and collaborative service delivery ("eGovernment services … developed in collaboration with third parties") and the equivalent to inter-agency partnering in the European context ("seamless cross-border eGovernment services … interoperability of eGovernment services and systems in the Single Market").

In the EU case, it was not easy to identify the Malmö Ministerial Conference Declaration as the policy kick-starter, namely because 'open government' does not appear to have been used as an umbrella term to describe the goals (policy priorities). Nevertheless, the Declaration does refer to specific implementation and monitoring actions and milestones, although the actual responsibility for its implementation is somewhat fuzzy.

Implementation path and impact

This section analyses the implementation paths followed once the initial policy documents were approved, and its impact both internally and externally.

The US case

The Obama Memorandum charged the Chief Technology Officer to develop an Open Government Directive with instructions to "executive departments and agencies to take specific actions implementing the principles set forth" in the memorandum.

In the same year (December) the Directive instructed those departments and agencies to take specific actions, such as improving the quality of government information and publishing it online by taking a proactive approach to FOIA, publishing at least three high-value data sets on Data.gov, and creating its own Open Government Webpage with a specified URL structure.

Agencies were also required to develop their own Open Government Plan, to be revised every two years. The Directive contained general guidelines about the main plan domains (transparency, participation, collaboration), required them to describe at least one specific new flagship initiative in one of these main domains, and provided guidelines on how the general public and agency employees should be included in the formulation process. The Directive also required each plan to be disclosed in the agency webpage. Some of these instructions came with a defined deadline for implementation.

Furthermore, the Directive planned the creation of an Open Government Dashboard "designed to provide an assessment of the state of open government". Although it was not possible to find this specific dashboard within the White House Open Government homepage 14 , the 'Open Government Working Group' webpage does provide a list of all agencies' dedicated open government homepages.

The analysis of the US Department of Justice general homepage, for instance, also revealed a direct link to its dedicated open government homepage 15 where all policy related information is available, including the Department's plans, actions and progress assessment.

With the exception of the requirements directed at federal agencies, and as far as the information available on the US open government homepage is concerned, no reference was found concerning the implementation of open government principles in the State and Local government.

Apart from this internal (federal) implementation path, the US also developed several Open Government National Action Plans to comply with the requirements of the Open Government Partnership (OGP). These plans were bound to "outline specific and measurable open government commitments … made within five "grand challenge" topic areas" 16 , and participating countries were required to assess and revise their own plans every two years. The OGP, launched in 2011 and currently involving 69 countries (including some EU Member States), may itself be considered as an example of the external impact of the US open government policy 17 .

The most prominent open data US portal, Data.gov, may also be considered as an example of the external influence of the US policy as it established the 'data.gov.<coun-try>' URL structure standard for this type of portal as the list of more than 300 similar portals around the world 18 illustrates. A quick search on Google Scholar also found several references which address Data.gov, thus showing its relevance as a study case for academia.

The EU case

The Malmö Declaration is clear about developing an eGovernment action plan which consider the policy priorities outlined. However, it clearly stated that these objectives were "proposed ways", "entirely without prejudice to the competencies exercised at European, national or sub-national level". The second eGovernment Action Plan [START_REF]The European eGovernment Action Plan 2011-2015: Harnessing ICT to promote smart, sustainable & innovative Government[END_REF] does indeed state that it "aims to realise the ambitious vision contained in the Declaration made at the 5th Ministerial eGovernment Conference (the 'Malmö Declaration')". Once again, there is no mention of the expression 'open government' in the plan. Instead, the Action Plan aims to support "the transition from current eGovernment to a new generation of open, flexible and collaborative seamless eGovernment services", that is, the terminology used emphasises 'Open eGovernment Services' rather than broad 'Open Government'.

In this Action Plan there seems to be no reference to specific actions to be further developed or implemented by EU Directorate-Generals as is the case of the US Administration Federal Agencies. Instead, the EU Commission recognizes "the central role of national governments in the implementation" of the action plan, and defines the Commission's main responsibility being "to improve the conditions for development of cross-border eGovernment services … establishing pre-conditions, such as interoperability, eSignatures and eIdentification" [12, p. 5].

The Action Plan also urged all Member States to incorporate the "political priorities of the Malmö Declaration in their national strategies" by 2013, and required "all Member States to inform the Commission and the High-Level Expert Group how the political priorities of the Malmö Declaration have been achieved" by 2015 [12, p. 15].

The structure of the Action Plan reflects four political priorities, including one termed "User Empowerment" which contains four sub-political priorities easily identified with the US Directive open government objectives: "Collaborative Production of Services", "Re-use of Public Sector Information"; "Improvement of Transparency"; "Involvement of citizens and businesses in policy-making processes". The remaining (sub-)political priorities could be more easily associated with traditional eGovernment development.

It was not possible to find any specific individual impact of the EU open government policy in the different European Commission Directorates-General, considered here as the equivalent to US Federal Agencies. In the case of the European Commission Directorate-General for Justice and Consumers, for instance, no reference to 'open government' was found on its homepage 19 , although a 'Transparency' area exists where it is possible to access a list of meetings held by the Director-General and Secretary-General (date, location, entities met, subject). Contrary to the US Department of Justice, searching for 'open government' in the Directorate-General search engine did not yield any significant result.

In what concerns the EU external policy impact, apart from the recommendations for its implementation by Member States, the EU current eGovernment benchmark exercise [START_REF]Delivering the European Advantage? 'How European governments can and should benefit from innovative public services' (eGovernment Benchmark Final Background Report[END_REF] also involves European Free Trade Association (EFTA) countries (thus being referred to as EU28+).

From the 'Open Data' section in the EU open government homepage it was possible to identify at least two EU level open data portals:  The European Union Open Data Portal20 (Open Data Portal of the EU institutions), currently holding 8017 datasets;

 The European Data Portal 21 , currently holding 386,027 datasets harvested from national (Member States) public data portals.

Although both portals were said to "target relevant user audience, offering tailored content" it was not clear why there were two different portals at the EU level. A quick search on Google Scholar found no relevant references to any of these portals, which may be considered as an indicator of its relatively low impact in the academia.

Monitoring and assessment

Apart from the implementation path, both the US and the EU open government policy frameworks call for several monitoring and assessment actions.

The US case

In the US case, monitoring and assessment comprises two dimensions: one directed at federal agencies compliance with the Memorandum and Directive; the other, with a national scope, assesses the OGP commitments fulfillment. Federal agencies and departments are responsible for the development, revision, and monitoring the progress of their own open government plans. Such plans and progress assessment should be available at their open government specific homepages, as listed in the Interagency Open Government Working Group section of the White House open government homepage (see section 2).

For instance, to assess the current status of the open government policy implementation in the US Department of Justice, it is possible to find in its homepage an "Open Government Progress Report" 22 .

From a global perspective, Wilson and Linders [14, p. 390] referred to a "White House's post-implementation" scorecard which could not be found. Instead, a status report from 2011 [START_REF] House | The Obama Administration's Commitment to Open Government Status Report[END_REF] is available at the White House open government homepage (see section 2), where the US National Action Plan and Self-Assessment Report are also accessible.

Furthermore, within the OGP website it is possible to find National Actions Plans, Self-Assessment Reports, Progress Reports and other documents, organized by country in a common site structure, depending on whether or not each country choose to submit it.

5.2

The EU case

The EU has been performing regular eGovernment benchmarking exercises since 2001 [START_REF]Summary Report: Web-based Survey on Electronic Public Services (Results of the first measurement[END_REF]. In the latest benchmarking report [START_REF]Delivering the European Advantage? 'How European governments can and should benefit from innovative public services' (eGovernment Benchmark Final Background Report[END_REF] there is no mention to the Malmö Declaration and just one use of the term 'open government' was found: "The results for user centric government (52%) and transparency (48%) make clear that the envisaged modern and open public sector, delivering public services in an open government setting (enabled by ICT), is far from reality." [13, p. 23] In a different document, the Midterm Evaluation of the eGovernment Action Plan 2011-2015 [16], it is indeed possible to find direct references to the Malmö Declaration and the term 'open government' (there is even a dedicated section called "Towards Open government"). This report "aims to provide a first measurement of the progresses that the European Commission and the Member States are making with respect to the vision stated in the Malmö Declaration" [16, p. 1]. As part of the assessment process, an eGovernment Action Plan-evaluation website23 was created to allow Member States to submit information on their progress. This website, which could not be found while browsing the Commission website, does indeed contain detailed data about each Member State self-assessment as well as two overall dashboards.

Overall, there seems to be a two path assessment effort (assessing the Action Plan implementation; eGovernment maturity benchmarking), something which is recognized in the Midterm Evaluation report: "The European eGovernment "Benchmarking" framework should be aligned with the eGovernment Action Plan and measure the outcomes. [16, p. 4] In 2011 an eGovernment Benchmark Pilot on Open Government and Transparency was performed [17] and the results were incorporated in the new 2012-2015 benchmark framework [START_REF]eGovernment Benchmark Framework 2012-2015: Method Paper[END_REF]. Efforts to develop a new eGovernment Action Plan 2016-2020 are already underway, this time under the banner of The Digital Single Market (DSM) Strategy for Europe [START_REF]eGovernment Action Plan 2016-2020 Roadmap[END_REF].

Discussion

There are similarities between the US and the EU open government policy frameworks: they were both initiated in 2009 and, most importantly, they share the same core principles and goals. But even if the core concepts are common, the EU open government policy documents and webpage content and structure directly emphasize its relation to public services innovation, while the US policy seems to have a broader scope and it is organized around three clear principles: transparency, participation and collaboration. Furthermore, the analysis seems to confirm that there is a major difference: while the US policy was designed and presented as a standalone framework, clearly formulated and implemented under a single umbrella term ('open government'), in the EU the option was to embed the same principles in an already existing eGovernment framework. As a result, in the US case the information is provided with greater visibility and simplicity in what concerns policy goals, implementation path and monitoring. In the EU case, the lack of usage of an autonomous umbrella term makes it more difficult from an outsider (ordinary citizen) point-of-view to find specific open government related policy information and to understand it. In a sense, it is more difficult to untangle the EU open government policy. This lack of an autonomous open government policy may also have contributed to a lesser external impact both in academia and other ('thirdparty') countries. For instance, the Obama Administration Memorandum and Directive is more recognizable as the origin of the US open government policy than the Malmö Declaration in the EU case, and the OGP creation is a good example of the US policy influence outside the US itself. Particularly in academia, the US Data.gov open data portal seems to have drawn much more attention than the two existing EU-level open data portals.

Another striking policy difference may be a result of the differences between a federal country (US) and an association of Member States (EU). In the US case, the policy implementation and assessment is directed at federal departments and agencies. Each agency has an obligation to elaborate its own plan, to assess and revise it periodically, and to disclose all the related information in a clearly identified online location. In the EU case, there seems to be no direct requirement for Directorates-General to develop and implement specific open government plans in their area, and Member States are simply "urged" to incorporate the Malmö Declaration policy principles into their individual national eGovernment strategies. As a consequence, progress in the EU case seems to be mainly assessed as part of the regular (from 2001) eGovernment maturity benchmarking exercises.

Conclusion

Since the US and the EU are two important policy development 'blocks' with influence in many countries worldwide, it is relevant to consider how they both defined and implemented their open government policy. The analysis results may provide guidance for other countries defining their open government policies, as well as for new policymaking processes.

In what concerns the issues listed in the Introduction, and despite the differences in nature between the US and the EU, the analysis found that it was more difficult to find information (online) concerning the EU process. Furthermore, as the list of references to EU reports in this paper may illustrate, it is not easy to form a clear picture of the whole EU policy framework. The way online information about open government is organized and structured, bundled with other apparently unrelated information, does not help either. On the contrary, the US defined a clear and simple process to implement and assess the policy, as well as a clear online structure (one webpage for each department or agency) to disclose policy-related information.

Although the core concepts and goals underlying both the US and EU open government policy were broadly the same, the US opted to define and maintain an autonomous open government policy, around well-defined principles, and always using the umbrella 'open government' term. This fundamental difference may have contributed decisively to a policy process that was easy to understand and follow, particularly from an ordinary citizen point-of-view. As a practical implication, we may conclude that new policy processes benefit from autonomy, simplicity and transparency, not only in the formulation stage, but also in what concerns its implementation and monitoring.

  21 http://www.europeandataportal.eu/ ("currently available in beta mode since November 2015") 22 https://www.justice.gov/open/department-justice-open-government-progress-report-december-2015

All online content was last accessed in January-March

https://www.whitehouse.gov

https://www.whitehouse.gov/open

https://www.whitehouse.gov/open/partnership

http://www.opengovpartnership.org/

Assesses the First National Action Plan

https://www.whitehouse.gov/open/about/working-group

http://ec.europa.eu/index_en.htm

https://ec.europa.eu/digital-agenda/en/open-government

https://ec.europa.eu/digital-agenda/en/open-data

https://ec.europa.eu/digital-agenda/en/ict-enabled-public-sector-innovation-horizon-2020

https://www.whitehouse.gov/open/documents/open-government-directive

https://ec.europa.eu/digital-agenda/en/ict-enabled-public-sector-innovation-horizon-2020

http://ec.europa.eu/justice/index_en.htm

https://open-data.europa.eu/en/data

http://www.egovap-evaluation.eu/

Acknowledgements. This work has been partially supported by the Fundação para a Ciência e a Tecnologia (FCT) under project grant UID/MULTI/00308/2013.


Ansgar Mondorf
email: mondorf@uni-koblenz.de

Maria A Wimmer
email: wimmer@uni-koblenz.de

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

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

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF]. 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 [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF][START_REF] Hjort-Madsen | Enterprise Architecture in Government: Fad or Future?[END_REF].

An EA framework is used to develop an enterprise architecture (EA) [START_REF] Armour | A big-picture look at enterprise architectures[END_REF]. 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 [START_REF] Winter | Article Essential Layers , Artifacts , and Dependencies of Enterprise Architecture[END_REF]. The resulting EA helps decision makers to proactively and comprehensively identify and analyse the execution of changes towards a desired vision and outcomes [START_REF] Armour | A big-picture look at enterprise architectures[END_REF].

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 [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF], [START_REF] Scholl | E-Government Integration and Interoperability: Framing the Research Agenda[END_REF], [START_REF] Scholl | Interoperability, Enterprise Architectures, and IT Governance in Government[END_REF]. The holistic view on ICT provided by EA frameworks is seen as a vehicle and means to overcome interoperability challenges [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF]. However, even though EAs are successfully used in the private sector, they are not yet appropriately adopted in government contexts [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF], [START_REF] Scholl | E-Government Integration and Interoperability: Framing the Research Agenda[END_REF]. Successful EA adoption depends on appropriate institutional forces and transformation processes [START_REF] Hjort-Madsen | Enterprise Architecture in Government: Fad or Future?[END_REF]. The use and effectiveness of EA is determined by the acceptance, coherence and governance of the architecture approach within the organizational context [START_REF] Janssen | Framing Enterprise Architecture: A Meta-Framework for Analyzing Architectural Efforts in Organizations[END_REF].

Hjort-Madsen and Pries-Heje argue that governmental EA is a means to improve efficiency of public services [START_REF] Hjort-Madsen | Enterprise Architecture in Government: Fad or Future?[END_REF]. Governmental EAs are based on different frameworks which vary in scope and specialization [START_REF] Armour | A big-picture look at enterprise architectures[END_REF], [START_REF] Zachman | A framework for information systems architecture[END_REF][START_REF]TOGAF Version 9.1[END_REF][START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF][START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF][START_REF] Armour | Enterprise architecture: agile transition and implementation[END_REF][START_REF] Spewak | Updating the Enterprise Architecture Planning Model[END_REF]. 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 [START_REF] Janssen | Sociopolitical Aspects of Interoperability and Enterprise Architecture in E-Government[END_REF]. Thus, EA can support governments to integrate relevant programs and projects and it provides elements such as standards, principles, technologies, services and building blocks [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF].

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) 1 and to initiate PEGS through a number of large-scale pilot projects (LSPs) 2 . LSPs run in different areas such as eHealth, eProcurement and eJustice. The e-SENS (Electronic Simple European Networked Services) 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 and the components they provide. The final section [START_REF] Scholl | Interoperability, Enterprise Architectures, and IT Governance in Government[END_REF] 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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF]. The EIF has stimulated the adoption of government interoperability frameworks (GIF) in the different MS [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF], [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF]. 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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF], [START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF]. GIFs like the EIF emphasize on technical, semantic and organizational aspects of interoperability. However, they neglect methodological support for projects and initiatives [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Kubicek | Three dimensions of organizational interoperability: Insights from recent studies for improving interoperability frameworks[END_REF]. Due to missing methodological support, GIFs only provide a limited assistance to interoperability initiatives and projects [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF].

Complementary to GIFs, EA frameworks offer assistance through methodological support in translating business visions and strategies into effective services [START_REF] Armour | A big-picture look at enterprise architectures[END_REF]. EA frameworks provide a multidimensional approach [START_REF] Zachman | A framework for information systems architecture[END_REF], [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF][START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF][START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF][START_REF] Kubicek | Three dimensions of organizational interoperability: Insights from recent studies for improving interoperability frameworks[END_REF]. They further detail the how, where, who, when and why next to the what which is addressed by GIFs [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF]. 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 [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF], [START_REF] Scholl | Interoperability, Enterprise Architectures, and IT Governance in Government[END_REF], [START_REF] Kubicek | Three dimensions of organizational interoperability: Insights from recent studies for improving interoperability frameworks[END_REF], [START_REF] Flak | Stakeholder Governance: Adapting Stakeholder Theory to E-Government[END_REF]. EA needs to respond to social interdependencies [START_REF] Janssen | Sociopolitical Aspects of Interoperability and Enterprise Architecture in E-Government[END_REF]. 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 [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF].

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 [START_REF] Zachman | A framework for information systems architecture[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF]. 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 [START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF], [START_REF]The Common Approach to Federal Enterprise Architecture[END_REF]. 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 [START_REF] Spewak | Updating the Enterprise Architecture Planning Model[END_REF], EITA aims to handle, manage and integrate multiple systems [START_REF] Armour | A big-picture look at enterprise architectures[END_REF], [START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF], [START_REF] Armour | Enterprise architecture: agile transition and implementation[END_REF]. 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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF], [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF], [START_REF]European Interoperability Strategy (EIS) for European public services[END_REF], [START_REF] Criado | Interoperability of eGovernment for Building Intergovernmental Integration in the European Union[END_REF]. 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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF], [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF], [START_REF] Criado | Interoperability of eGovernment for Building Intergovernmental Integration in the European Union[END_REF]. 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 [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF]. 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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF]. 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 [START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF]. Gøtze et al. assess national EA programs and show how these programs serve as precursors for crossborder collaborations. The analysis points to major obstacles and drivers for cross-border collaborations [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF]. Kubicek et al. review important GIFs, develop a four-layer framework and provide guidance for their re-conceptualization [START_REF] Kubicek | Organizational Interoperability in E-Government -Lessons from 77 European Good-Practice Cases[END_REF]. 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.

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 [START_REF] Hevner | Design Science in Information Systems Research[END_REF].

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 [START_REF] Hevner | Design Science in Information Systems Research[END_REF].

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 [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF], [START_REF] Attride-Stirling | Thematic networks: an analytic tool for qualitative research[END_REF]. The organizing themes enrich the qualitative research design and support the study of the socio-technical phenomena of the EA framework for PEGS [START_REF] Hjort-Madsen | Enterprise Architecture Implementation and Management: A Case Study on Interoperability[END_REF].

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.

Requirements related to the management of interoperability projects (PM)

E-government interoperability cannot be achieved by focusing on technical issues alone [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF][START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF][START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF]. 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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF]. An EA framework for PEGS should adopt and promote highlevel policies on interoperability [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF]. It should provide means to ensure sufficient toplevel management and political support, which is a critical factor when realizing crossnational collaborations PM05 [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF]. 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 [START_REF] Santos | Barriers to Government Interoperability Frameworks Adoption[END_REF].

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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF], [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF].

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 [START_REF] Janssen | Sociopolitical Aspects of Interoperability and Enterprise Architecture in E-Government[END_REF]. 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 [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF], [START_REF] Flak | Stakeholder Governance: Adapting Stakeholder Theory to E-Government[END_REF].

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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF]. 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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF], [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF]. Service development should rather concentrate on business-driven needs than to lay its focus on technology or advancement-driven opportunities SD01 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF]. Business requirements identify the scope of reform and help to find commonalities among agencies [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF]. Implementations may be realized in several ways because interoperability shall encourage openness and a variety of solutions in the software industry SD05 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF].

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 [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF]. 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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF][START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF][START_REF] Guijarro | Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States[END_REF].

The EA framework for PEGS should make clear how to use interoperability layers and architecture viewpoints to address different stakeholder needs and views LV04 [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF], [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF]. Layers and viewpoints support the analysis of business related concepts as well as the alignment of IT systems and collaboration towards a shared vision [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF], [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF]. Thus, interoperability layers and architecture viewpoints follow a similar approach with different intentions. A link between them should be provided LV01.

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 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF]. Aggregate public services are typically constructed by grouping several service components into a coherent whole BB02 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF]. 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 [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF]. 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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF].

Requirements related to the provision of collaboration agreements (CA)

Collaboration agreements ensure a successful interaction and are preferred means to achieve interoperability [START_REF]European Interoperability Framework (EIF) for European public services[END_REF], [START_REF] Scholl | E-Government Integration and Interoperability: Framing the Research Agenda[END_REF]. Interoperability requires the publication of agreements (methods, specifications, standards) that describe the ways of interoperation CA02 [START_REF] Scholl | E-Government Integration and Interoperability: Framing the Research Agenda[END_REF].

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 [START_REF] Janssen | Guest Editors' Introduction: Egovernment Interoperability, Infrastructure and Architecture: State-of-the-art and Challenges[END_REF].

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 [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF], [START_REF] Klischewski | Architectures for tinkering? Contextual strategies towards interoperability in E-government[END_REF]. Next to a good cooperation ability [START_REF] Ray | A critical survey of selected government interoperability frameworks[END_REF], 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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF]. 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 [START_REF] Charalabidis | A Comparative Analysis of National Interoperability Frameworks[END_REF], [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF].

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 requirements, 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 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 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], [START_REF]TOGAF Version 9.1[END_REF], [START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF]. 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 [START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF]. According to the EIF, European-wide and sector-specific architecture solutions are the envisioned levels of scope for PEGS OPN-PM04 [START_REF]European Interoperability Framework (EIF) for European public services[END_REF]. The concept of primary outcomes represents areas of an EA framework where a direct, positive impact can be made [START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF]. The primary outcomes of an EA framework for PEGS are service delivery, cooperation, information exchange, sharing and reuse and reduction of costs [START_REF]European Interoperability Framework (EIF) for European public services[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF], [START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF], [START_REF] Janssen | Government Architecture: Concepts, Use and Impact[END_REF]. 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 [START_REF]Federal Enterprise Architecture Framework -Version 2[END_REF], [START_REF] Janssen | Government Architecture: Concepts, Use and Impact[END_REF].

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 [START_REF]TOGAF Version 9.1[END_REF].

Architecture meta-models clarify various EA concerns. While the Zachman framework puts forward different perspectives on information systems, enterprise analysis and modelling [START_REF] Zachman | A framework for information systems architecture[END_REF], 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 [START_REF]Systems and software engineering -Architecture Description (ISO/IEC/IEEE 42010)[END_REF]. 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 [START_REF] Buckl | Enterprise Architecture Management Patterns --Exemplifying the Approach[END_REF].

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 [START_REF] Winter | Article Essential Layers , Artifacts , and Dependencies of Enterprise Architecture[END_REF].

Links to the operational level can be best established through requirements management, a central activity of the EA life-cycle (cf. section 5.3) OPN-SD01 [START_REF]TOGAF Version 9.1[END_REF]. EA viewpoints can be easily mapped to interoperability layers as shown in [START_REF] Gøtze | Cross-National Interoperability and Enterprise Architecture[END_REF] 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 [START_REF] Lankhorst | The Architecture of the ArchiMate Language[END_REF], [START_REF]ArchiMate 2.1 Specification[END_REF].

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-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. 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- ST 03 [START_REF]TOGAF Version 9.1[END_REF], [START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF], [START_REF] Spewak | Updating the Enterprise Architecture Planning Model[END_REF]. 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], [START_REF] Armour | Enterprise architecture: agile transition and implementation[END_REF], [START_REF] Spewak | Updating the Enterprise Architecture Planning Model[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF], [START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF], [START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF], [START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF], [START_REF] Spewak | Updating the Enterprise Architecture Planning Model[END_REF]. 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 [START_REF]TOGAF Version 9.1[END_REF], [START_REF] Armour | Building an Enterprise Architecture Step by Step[END_REF], [START_REF] Spewak | Updating the Enterprise Architecture Planning Model[END_REF].

Fulfilment of requirements through EA components

In the previous sub-sections, several EA components were identified, examined and rearranged. 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 [START_REF]Systems and software engineering -Architecture Description (ISO/IEC/IEEE 42010)[END_REF], TOGAF content framework or TOGAF enterprise continuum [START_REF]TOGAF Version 9.1[END_REF]. 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 [START_REF]ArchiMate 2.1 Specification[END_REF].

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.

PM02

ArchiMate distinguishes between different types of services. Each service type can be defined and changed independently.

SD04 BB02

Establishment of links between interoperability layers and architecture viewpoints.

LV01

Integrating semantic, organizational and legal aspects of interoperability layers into the information architecture, business architecture and strategy viewpoint.

LV02

ArchiMate models provide capabilities to collaborate and agree on service components.

BB06 EA process components (life-cycle)

Sequential phases of ADM ensure top-down processing.

PM01

Combination of sequential and central phases. Requirements Management provides bridge between strategy and operation.

PM02

Planning & Initialization and Architecture Vision phase clarify how to initialize interoperability projects

PM03

Stakeholder Management phase and TOGAF guideline and techniques on Stakeholder Management help to manage various concerns.

PM05

TOGAF guideline on Interoperability Requirements can be used to visualize crossorganizational relationships.

ST02

Repository Management Phase and TOGAF Architecture Repository help to organize architectures outcomes.

BB05

Stakeholder Management phase offers possibility to introduce formalized stakeholder approval and change processes.

CA02

Standard & Technology Management phase clarifies when to establish, select and validate standards and technologies and how to use them as architecture foundations.

CA05

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

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. [START_REF] Scholl | E-Government Integration and Interoperability: Framing the Research Agenda[END_REF] 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 [START_REF]ArchiMate 2.1 Specification[END_REF].

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. [START_REF] Zachman | A framework for information systems architecture[END_REF] 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. [START_REF]TOGAF Version 9.1[END_REF] 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.

Fig. 1 .

 1 Fig.1. EA LCM for PEGS adapted from[START_REF]TOGAF Version 9.1[END_REF]

Table 1 .

 1 Fulfilment of architecture requirements through EA componentsPrimary outcomes, levels of scope and basic elements (principles, methods, tools, patterns and standards) ensure that EA programs are complete and effective.

	ARE	EA COMPONENT DESCRIPTION	NR
	A
	Contextual EA	components	TOGAF content framework structures architectural content and shows how to com-pose aggregate public services. TOGAF enterprise continuum provides method how to adapt architectures and solutions to certain contexts ISO/IEC/IEEE std. 42010: 2011 clarifies how to create, analyse & sustain architectures using architecture descriptions	ST02 BB04 BB05
	EA content compo-	nents (viewpoints)

PM03

TOGAF Deliverables: Stakeholder Contract, Change Request, Request for Architecture Work and Communication Plan.

Use of strategy viewpoint to drive architecture development

PM01

Inclusion of strategy viewpoint.

EIRA: https://joinup.ec.europa.eu/node/99464

LSPs: https://ec.europa.eu/digital-agenda/en/large-scale-pilot-projects

E-SENS: http://www.esens.eu/