Organizational Interoperability in E-Government
.
Herbert Kubicek Ralf Cimander Hans Jochen Scholl l
Organizational Interoperability in E-Government Lessons from 77 European Good-Practice Cases
Herbert Kubicek Ralf Cimander Institut fu¨r Informationsmanagement Bremen (ifib) Am Fallturm 1 28359 Bremen Germany
[email protected] [email protected]
Hans Jochen Scholl University of Washington Information School Mary Gates Hall Seattle, WA 98195-2840 USA
[email protected]
ACM Codes: J.1, K.4.3, H.4, H.3.5 ISBN 978-3-642-22501-7 e-ISBN 978-3-642-22502-4 DOI 10.1007/978-3-642-22502-4 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011935046 # Springer-Verlag Berlin Heidelberg 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)
Preface
In the e-government research community as well as in many national e-government programs interoperability is widely seen as a key factor in developing effective and attractive e-services for citizens and business. Also, researchers agree that interoperability is about more than mere technical standards and interfaces; rather it encompasses organizational, legal, and cultural aspects as well. Most importantly perhaps, interoperability might present a challenge to traditional ways of governance in the public sectors by requiring new ways of intergovernmental cooperation. So far, however, little is known about which configurations of information technology (IT) governance have evolved in practice over the years to achieve interoperation in e-government and how governance of the public sectors might be impacted by interoperability within the broader frameworks of connected or networked government. Several interoperability frameworks have been introduced on national and international levels. Recommendations have been made for the adaptation of enterprise architectures in the public sector. Also, maturity models have been proposed, some of which introduce various degrees of formal and abstract categories for setting up a governance structure for interoperability in government. Common to these contributions is their top–down deductive approach, which seemingly does not connect well to the real world of e-government projects. In contrast, in this volume, based on empirical research, we introduce and present a bottom–up inductive approach to understanding the challenges of interoperability-related governance. Based on so-called “good-practice” cases of interoperability in e-government we derive concepts and classifications, which help uncover and assess similarities and differences between the cases. As a result, we were able to put forward an empirically based conceptual framework that details the options for IT governance of interoperability in government. Our findings also allow us to critically discuss, assess, and re-conceptualize the existing frameworks and determine how those could be improved. We conducted the research study in three phases. The first two authors were part of a consortium, which collected, assessed and documented good-practice cases of
v
vi
Preface
interoperability in e-government for the European Commission. In the first study on back-office reorganization, which had been carried out in cooperation with the Danish Technological Institute, a total of 29 cases were identified and documented. In the second project, the Study on Interoperability at Local and Regional Level additional cases were collected, written up and published on the e-practice portal of the European Commission as well as on a special website, offering a searchable data base of 177 cases from all over Europe. This study had been conducted in the MODINIS program of the European Commission in cooperation with the European Institute of Public Administration (EIPA) in Maastricht, Netherlands, and the Center for Research and Technology Hellas/Informatics and Telematics Institute (CERTH/ITI) in Thessaloniki, Greece. The aim of both studies was to document and publish the cases such that lessons learned would be shared among interested governments and practitioners. These studies, however, would not satisfy the strict criteria of a scientifically designed comparative analysis. The opportunity for comparative coding of the individual descriptions came only when the Deutsche Forschungsgemeinschaft (the national research funding organization in Germany) funded this research in 2008 for 2 years. The first two authors developed a conceptual framework and a coding scheme for recoding more or less successful cases of interoperation, presented this framework at several conferences, revised it and together with the support of a Master’s student applied it to 77 cases. In the final phase, the third author joined the team, introduced additional theoretical foundations, which were used for additional coding. This also initiated a dialogue about how these empirical findings relate to recent concerns regarding IT governance and enterprise architectures in government. Combining different thematic foci as well as a European and a US background this volume puts empirical research into the broader context of theoretical and political reflection. We want to thank our colleagues with whom we cooperated in the back-office and in the MODINIS study, Jeremy Millard, Jonas Svara Iversen and Hilmar Westholm, Christine Leitner, Sylvia Archman and Immanuel Kudlacek (EIPA) as well as Efthimios Tambouris, Konstantinos Tarabanis, Vassilios Peristeras and Naoum Liotas (CERTH/ITI), Thomas Schro¨der for his support in coding, Rebecca Romppel for setting up the database, Anne Bausch for producing several versions of the typescript, and the DFG for funding an important part of this research.
Bremen and Seattle, June 2011
Herbert Kubicek Ralf Cimander Hans J. Scholl
Contents
1
2
3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 High Expectations for E-Government . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Front-Office and Back-Office Public Services . . . . . . . . . . . . . . . . . . . . . . . 1.3 The Importance of G2G Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 The Relevance of Interoperability for E-Government Progress . . . . . 1.5 The Relevance of Interoperability Beyond Public Services . . . . . . . . . 1.6 Interoperability Strategies of the European Commission . . . . . . . . . . . . 1.7 The Need for Standardization and the Role of Interoperability Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8 Progress with EIF 2.0? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.9 Exploring Organizational Interoperability and Governance Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.10 Objectives of This Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.11 Outline of This Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interoperability in Government . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Historical Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 The Emerging Need for Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 The OSI Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Governance and IT-Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Two Contexts and Meanings of Governance . . . . . . . . . . . . . . . . . . 2.3.2 IT Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 The Public-Private-Distinction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Integration, Centralization and Standardization: Technical and Organizational Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Stakeholders’ Information Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 2 5 7 8 10 11 13 14 14 17 17 18 19 22 25 25 26 27 28 29
Review of Prominent IFs and the Need for Re-conceptualization . . . 35 3.1 Purpose and Structure of IFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
vii
viii
Contents
3.1.1 Forerunners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Interoperability Policy Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Purpose and Relevance of EIF 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Building Blocks and Key Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 The Political Controversy About Openness . . . . . . . . . . . . . . . . . . . Building Blocks of EIF 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enterprise Architectures and Reference Models . . . . . . . . . . . . . . . . . . . . . 3.3.1 Broader Reference Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparisons of National Interoperability Frameworks . . . . . . . . . . . . . . 3.4.1 Political Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Legal Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Layers of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relevance and Fuzziness of Organizational Interoperability . . . . . . . . Basic Idea for Re-conceptualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 The Functional View – “What” Has to be Standardized? . . . . 3.6.2 IT Governance (The Institutional View): “Who” Defines Standards? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 The IT-Service View: “How” Is Interoperability Implemented? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36 37 38 39 39 43 46 48 49 50 52 54 55 58 62
4
Selection and Classification of Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Case Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Case Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Distribution by Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Distribution by Level of Government . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Coding of Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65 65 67 68 69 69 70
5
Interdependencies in E-Government and Their Interoperability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Horizontal and Vertical Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Different Types of Interdependence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Different Types of Interoperability Requirements . . . . . . . . . . . . . . . . . . . 5.3.1 Multi-service Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Multi-Stage Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Multi-area Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 Multi-file Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71 71 73 74 74 75 76 77
6
Wants and Needs When Pursuing Interoperability . . . . . . . . . . . . . . . . . . . 6.1 Interoperability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Levels of Government . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79 81 83 83
7
Layers of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.1 Technical, Syntactic and Semantic Interoperability . . . . . . . . . . . . . . . . . . 85
3.2 3.3 3.4
3.5 3.6
63 63
Contents
7.1.1 Technical and Syntactic Interoperability . . . . . . . . . . . . . . . . . . . . . . 7.1.2 Semantic Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Organizational Interoperability Re-defined . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Cumulative Structure of Interoperability Layers . . . . . . . . . . . . . . . . . . . . .
ix
86 89 91 94
8
Modes of Implementation of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.1 Standardization for Interoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 8.2 Centralization for Interoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.3 Relationship Between Standardization and Centralization . . . . . . . . . 106 8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9
IT Governance of Collaboration for Interoperability . . . . . . . . . . . . . . . 9.1 The Planning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Institutional Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.2 Representation of Agencies Concerned . . . . . . . . . . . . . . . . . . . . . . 9.2 Legitimacy and Authorization of Standards . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Operation and Maintenance of Standards . . . . . . . . . . . . . . . . . . . . . . . . . .
109 112 112 116 118 122
10
Strategic Choices for Setting Up Interoperable E-Government Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Choosing an IT Governance Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Choosing an Organizational Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Selecting and Defining Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Enacting Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6 Implementation and Supporting of Interoperation . . . . . . . . . . . . . . . . 10.7 Evaluation and Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
127 128 129 130 131 132 132 133
11
Interoperability Beyond Interoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 11.1 Interoperability as Capability and Generic Components . . . . . . . . . 136
12
Conclusions and Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Annex 1: List of 77 Good-Practice Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Annex 2: Summaries of Good-Practice Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Annex 3.1: Ranking of Cases According to Number of Layers Covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Annex 3.2: Cumulative Structure for Standardization Items . . . . . . . . . . . . . 177 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
.
Abbreviations
ADP AEAT ARPANET BPML CAD CBSS CEC CERTH/ITI CIO CIOC CNIPA
CNMSI COBIT CRR CRS CTG CTO DISC DSFA DVDV DoH DOL DSFA DWP EA EAG
Automatic Data Processing Agencia Tributaria, Spanish Tax Administration Data Portal Advanced Research Projects Agency Network Business Process Modeling Language Codice dell’Amministrazione Digitale, Italy Cross Roads Bank for Social Security Commission of the European Communities Center for Research on Technology Hellas/Informatics and Telematics Institute Chief Information Officer Chief Information Officer Council Centro Nazionale per Informatica nella Pubblica Amministrazione (National Center for Informatics in Public Administration) Italy Centre for the Management of Information Society, Romania Control Objectives for Information and Related Technology Central Registration Register, Austria Central Records System, Ireland US Center for Technology in Government Council, Chief Technology Officer Council, UK Departmental Integrated Services Connector Department of Social and Family Affairs, Ireland Deutsches Verwaltungsdiensteverzeichnis, Directory of the German Administration Services Department of Health, UK Deutschland Online (Germany Online) Department of Social and Family Affairs, Ireland Department of Work and Pensions, UK Enterprise Architecture E-Government Enterprise Architecture Guidance
xi
xii
EAN ebMS EDI EDIAKT EDIFACT eGif EIF EIPA EIS ELAK EPAN EPS eSDF ETSI EU FRAND terms FTP GOSIP GRO GtoB GtoC GtoG HTTP HTTPS IAMS ICT IDABC IF ifib IOP IOS IS ISA ISDN ISO IT ITGI KIS KoopA ADV
Abbreviations
European Article Number E-Business Message Service Specification Electronic Data Interchange Electronic Data Interchange Akt, Austria Electronic Data Interchange For Administration, Commerce and Transport E-government Interoperability Framework, UK European Interoperability Framework European Institute for Public Administration European Interoperability Strategy Elektronischer Akt, Austria European Public Administration Network Electronic Payment Standard e-Services Development Framework European Telecommunications Standards Institute European Union Fair, reasonable, and non-discriminatory terms File Transfer Protocol Government Open Systems Interconnection Profile, USA General Register Office, Ireland G2B, Government to Business G2C, Government to Citizens G2G, Government to Government Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Inter Agency Messaging Service, Ireland Information and Communication Technologies Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens Interoperability Framework Institute for Information Management Bremen, Germany Interoperability Inter-organizational Information Systems Information System Interoperability Solutions for European Public Administrations, European Commission Integrated Services Digital Network International Standards Organization Information Technologies IT Governance Institute Kunden-Informations-System Kooperationsausschuss von Bund und La¨ndern automatisierte Datenverarbeitung, Germany
Abbreviations
LETS MF MoA MODINIS MSTI NIF NIFO NIST NORA ODETTE – OFTP OECD OIO Committee OMB OPAC OSCI OSI OSS PIN POSIT PPP PPSN RTA s-TESTA SAGA SLA S/MIME SMTP SNA SOA SPC Italy SPO SSL SWIFT TAN TCP/IP TERREGOV TIEKE
xiii
Leeds Electronic Tendering Service, UK Ministry of Finance, Denmark Memorandum of Understanding Ministry of Science, Technology and Innovation, Denmark National Interoperability Framework National Interoperability Framework Observatory National Institute of Standards and Technology, USA Nederland Overheidsreferentie Architectuur Odette File Transfer Protocol Organization for Economic Co-operation and Development Open public Information Online Committee, Denmark Office of Management and Budget of the Executive Office of the President of the United States Online Public Access Catalog Online Services Computer Interface Open System Interconnection Open Source Software Personal Identification Number Profiles for Open Systems Internetworking Technologies Public–Private Partnership Personal Public Service Number, Ireland Road Traffic Accident UK Secured Trans European Services for Telematics between Administrations Standards und Architekturen fu¨r E-Government-Anwendungen Service Level Agreement Secure/Multipurpose Internet Mail Extensions Simple Mail Transfer Protocol System Network Architecture Service-Oriented Architecture Public Connectivity and Cooperation System State Planning Organization, Turkey Secure Sockets Layer Society for Worldwide Interbank Financial Telecommunication Transaction Number Transmission Control Protocol/Internet Protocol Impact of E-Government on Territorial Government Service, EU Project Tietoyhteiskunnan Kehitta¨miskeskus Ry, Finnish Information Society Development Centre
xiv
UN/CEFACT UNCTAD UN/ECE UPC VAN VPN WSDL XML ZMR
Abbreviations
United Nations Centre for Trade Facilitation and Electronic Business United Nations Conference on Trade and Development UN Economic Commission for Europe Universal Product Code Value-Added Network Virtual Private Network Web Services Definition Language Extensible Markup Language ¨ sterreich (Central Registration Zentrales Melderegister O Authority, Austria)
Chapter 1
Introduction
For more than 10 years, expectations about the Internet’s potential to change the relations between citizens and their governments at the political, democratic level and with regard to public services for citizens and business have been high.
1.1
High Expectations for E-Government
By providing public services via the Internet, it was thought that public services would become more customer-centered and efficient. Already in 1995, US President Bill Clinton and Vice President Al Gore had promised in their Agenda for Action a government that works better and costs less (IITF 1993, see also Kubicek and Dutton 1997 as well as Kalil 1997). The terms “digital government”, “electronic government” or “e-government” were coined in the US and Europe respectively (see Scholl 2010) and became both a political objective and part of action plans all over the world (OECD 2003; United Nations 2003). In Europe, not only the Member States but also the European Commission and the European Council developed their e-government objectives and work programs (CEC 2000, see also Alabau 2005 for a summary). As these have to be approved by the ministers of the Member States, these decisions reflect some kind of common understanding of this field in Europe. The European Commission defines e-government as “the use of information and communication technologies in public administrations – combined with organizational change and new skills – to improve public services and democratic processes and to strengthen support to public policies” (CEC 2003, p. 7). According to Commission documents, by e-government public administrations will become • More open and transparent, reinforcing democratic participation; • More service-oriented, providing personalized and inclusive services to each citizen; • More productive, delivering maximum value for taxpayers’ money (p. 8). H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_1, # Springer-Verlag Berlin Heidelberg 2011
1
2
1 Introduction
By information and communication technologies (ICT or IT) all kinds of hardware, software, and networks are summarized, but particular relevance is given to internet and mobile technology and their application.
1.2
Front-Office and Back-Office Public Services
Public services are services delivered by government agencies to the public, in a broad sense including sectors such as public education, healthcare, transportation, broadcasting, waste management, social welfare, public safety among others. In e-government, public services and the respective communication can be grouped in the following ways: • Government to Citizens (G2C), e.g. tax declarations, applications for social benefits, requests for birth certificates or driver’s licenses; • Government to Business (G2B), e.g. social contributions for employees, declarations of corporate tax, and different kinds of permits for export, environmental emissions; • Government to Government (G2G), e.g. access to central registries by local authorities, sharing of information resources
1.3
The Importance of G2G Reorganization
Many G2C and G2B services depend on well functioning G2G communication. This relationship can be explained by distinguishing between front-and back-offices (see Fig. 1.1). Citizens and businesses as customers apply for a service at a physical or virtual front office of a public agency that provides that particular public service. In order to provide this service, in some cases another unit of the same agency has to confirm certain data, or a unit of another agency has to be consulted. Therefore another unit in this agency or another computer program forwards data or starts a request to another agency. Thus intra- and/or interagency exchange of data between back-offices, i.e., without involving the customer, is necessary in order to provide the service to the citizen or business. The above-mentioned objectives of better service quality and more effective delivery can be improved if the services are not simply supported electronically in the way they were produced and delivered in the past, but if a reorganization of front- and back-office communication takes place. Three examples from a study
1.3 The Importance of G2G Reorganization
3
Fig. 1.1 Front- and back-office communication in e-government
conducted for the European may illustrate the potential that back-office reorganization entails.1 Prior to back-office reorganization, when applying for child allowance in Ireland (case no. 1), parents had to submit a document from the hospital about the birth of their child to the registrar who officially confirmed the birth by issuing a birth certificate. The parents then had to take this certificate to their local civil registration office, which registered the new citizen in the civil registry and provided a registration confirmation. Only with this document were parents entitled to apply for a child allowance (Fig. 1.2, left box). To relieve the bureaucratic burden on parents and offices, an integrated work flow between the back-offices of the three agencies involved needed to be constructed: Now, the parents apply for child allowance in the hospital; the hospital adds the data of the birth and forwards the electronic application form to the registrar; the registrar registers the birth, adds the data, and forwards the form to the civil register; the civil register states this on the form and, finally, forwards it to the Office of Family Affairs (Fig. 1.2, right box). The second example is the compilation of income tax declarations in Spain (case no. 2) and all Scandinavian Countries. As in many other countries, taxpayers have to collect documents confirming their salaries, social benefits, and interest from bank accounts and attach them to their income tax declaration (Fig. 1.3). In Spain, employers, banks, and social welfare agencies have been obliged to send these data directly to a newly established central Spanish tax administration data portal (AEAT). Citizens as taxpayers can download the data and confirmations
1 Numbers refer to short summaries in Annex 1. There, reference is made to a full case description delivered to the e-practice portal.
4
1 Introduction
Fig. 1.2 Applying for child allowance in Ireland – before and after back-office reorganization
from this portal. The regional tax offices also have access to the data and therefore no longer require documents from the taxpayer (Fig. 1.3, right box).
Fig. 1.3 Provision of documents for income tax declarations
The pro-active compilation of income tax declarations in the Scandinavian countries is even more convenient. Employers, banks, and social welfare agencies send their data to the tax office, which produces a proposal for each citizen’s tax declaration and sends it to the citizen. If the citizen does not demand any corrections or claim any expenses as tax-deductible, he or she may confirm this proposal by e-mail or telephone. On average, between 70% and 80% of all proposals are confirmed, leading to savings of several million Euros each year.
1.4 The Relevance of Interoperability for E-Government Progress
5
A third example deals with the registration of citizens when moving from one local community to another. Many countries have a central national civil register. In Germany, however, civil registration was decentralized to 5,283 local registers (case no. 3). Therefore, citizens had both to deregister in their old community and to register in their new one. This entailed providing the same data to the same kind of agency in two different locations. And if people did not deregister, they were registered twice, and the population data became unclean. In order to relieve citizens from this burden and to improve data validity, the law was changed. Now, citizens only have to register in the new community, which forwards their information to the old community for deregistration. In order to allow for this data exchange between different ICT systems a standard data exchange format was defined, and a corresponding interface was made mandatory by law.
1.4
The Relevance of Interoperability for E-Government Progress
The three cases do not only refer to different countries but also show different ways or models for back-office reorganization. While in the Irish case several backoffices are linked in a sequential way, in the tax-related cases data from different sources are integrated in a central database. In both cases the workflows and the software of the application systems have to be adapted and changed. In the German case of civil registries local government had more than ten different software systems in use for the local civil registries and they were not ready to change their local systems. By development of a common data exchange format only interfaces had to be added to these different local systems in order to convert incoming and outgoing data (see Fig. 1.4). In technical terms the cases require an exchange of data between formerly separated ICT-systems. They have to be made interoperable. But too often old legacy systems cannot be connected to the Internet, or different government units have implemented systems that do not allow for the fully automatic exchange
Fig. 1.4 Standard data exchange between different application systems
6
1 Introduction
Table 1.1 eEurope common list of 20 basic public services (CEC 2001a, p. 19) Public services for citizens 1. Income taxes: declaration, notification of assessment 2. Job search services by labor offices 3. Social security contributions: (a) unemployment benefits, (b) family allowances, (c) medical costs (reimbursement or direct settlement), (d) student stipends 4. Personal documents: (a) passport, (b) driver’s license 5. Car registration (new, used and imported cars) 6. Application for building permission 7. Declaration to the police (e.g. in case of theft) 8. Public libraries (availability of catalogues, search tools) 9. Certificates, request and delivery: (a) birth, (b) marriage 10. Enrolment in higher education/university 11. Announcement of moving (change of address) 12. Health related services (e.g. interactive advice on the availability of services in different hospitals; appointments for hospitals) Public services for businesses 13. Social contribution for employees 14. Corporation tax: declaration, notification 15. VAT: declaration, notification 16. Registration of a new company 17. Submission of data to statistical offices 18. Customs declarations 19. Environment-related permits (incl. reporting) 20. Public procurement
of data between these agencies. That is, there is a lack of integration or interoperability (IOP), which encompasses a complex, multidimensional, and multidisciplinary set of factors (see Scholl and Klischewski (2007), Charalabidis et al. (2011), Pardo et al. (2011) with many references). Academics worldwide have little doubt that this lack of interoperability leads to missing out on fully reaping the potential benefits of e-government (see Scholl and Klischewski (2007), Charalabidis et al. (2011), Pardo et al. (2011) with many references). For European governments slow progress in e-government is well documented by a regular benchmarking, which the European Council ordered for monitoring progress of their e-government programs. In 2000, the European Council, i.e., the ministers responsible for public services in the Member States, set the ambitious target of putting all basic public services online in bi-directional mode by the end of 2003 (CEC 2000, pp. 22–23). Twenty basic public services had been agreed upon as a reference list, and regular benchmarking of the degree of interactivity of online services among the Member States was tracked in these areas (CEC 2001a, p. 19) (see Table 1.1). The first benchmarking report was published in November 2001 (CEC 2001b), the fifth one in March 2005 (CEC 2005). The average degree of online sophistication, i.e., the degree to which case handling is fully electronic and services are delivered entirely online, had reached 77% for services to business and 57% for services to citizens by the end of 2004. In comparison to the previous measurements,
1.5 The Relevance of Interoperability Beyond Public Services
7
a stabilization of the measures within the EU 15+ countries could be stated. But still almost half of the services to citizens were not offered completely online. Within the eEurope 2005 program, e-government became a policy priority and e-government targets became part of the eEurope 2005 Action Plan, including a Commission’s Communication on the role of e-government for Europe’s future. In April 2006 the European Commission launched the “i2010 eGovernment Action Plan: Accelerating eGovernment in Europe for the Benefit of All” (CEC 2006a). In the benchmarking report of the European Commission, back-office integration and interoperability are mentioned as an important factor in an Integrated E-government Model (CEC 2005, p. 8) but are not measured within the benchmarking scores. In November 2003, the European Council adopted a Communication of the Commission “The Role of eGovernment for Europe’s Future”. In this communication, a lack of interoperability was stressed, and the Commission emphasized that e-government is not just about technology but rather is a broad concept of modernization of public administration including reorganization and development of new skills and cultures (CEC 2003, pp. 18–21).
1.5
The Relevance of Interoperability Beyond Public Services
The relevance of interoperability would be greatly underestimated if it is only considered in terms of progress in public services directly delivered to citizens or business (CEC 2010a, Annex 2, p. 2). There are other public services where much more is at stake because of missing interoperability between ICT systems of different agencies (see also the briefing document for government leaders prepared by the Center for Technology in Government (CTG), Pardo and Burke 2008a, b): • Quite often, when emergency situations arise we hear that delays in providing necessary support and relief occurred due to a lack of cooperation between different agencies. In almost every case, a lack of access to mutually relevant data and barriers to the exchange of data are a primary reason for these deficits. • With regard to safeguards for public safety, including anti-terrorism efforts, missing exchange of data between different authorities reduces efficacy. • Similarly, in law prosecution, particularly across borders within the European Union, although legal provisions for information sharing exist, technical and organizational barriers prevent adequate exchange of information. • Many governments in Europe have recently declared a move towards more open government to increase transparency and allow for more participation. This requires easy access to government data across organizational boundaries. Taking into consideration the large public budget deficits, we can expect a growing need for improvement in the efficiency of public administration. interoperability is a means to reduce ICT-related costs and therefore becomes more important in ICT procurement by public agencies and in connection with
8
1 Introduction
broader strategies of reorganizing the use of ICT in new cooperation under the heading of networked government. According to Charalabidis et al. the Yankee Group estimates that if IT departments successfully implemented interoperability, they would be able to reduce costs by more than one third (Charalabidis et al. 2011, p. 356).
1.6
Interoperability Strategies of the European Commission
The European Commission developed two strategies to motivate and support MS to improve the provision of integrated e-government services and interoperability: • The Good-Practice Strategy, i.e., through collection and publication of good practice examples and identified via the bi-annual eEurope award and an Internet portal; • The Framework Strategy, i.e., through studies on integration and interoperability, and an Interoperability Framework. The Good-Practice Strategy assumes that a government can learn from examples realized in other countries and advises that countries lagging behind in the benchmark look at examples of countries with better rankings. Additional motivation should come from a competitive element provided by biannual awards in combination with a ministerial conference in which a selected number of projects are nominated for an award by a jury and presented in an exhibition before a few of them receive an award. This competition might compel ministers attending the conference without nominations for cases from their home country to increase the national efforts leading up to the next conference. The award strategy depends on the submissions of cases by their case owners. In addition, the Commission ordered a study for identifying good-practice cases which so far, for whatever reason, has not been submitted. The first two authors of this report were part of the team that carried out such a study for the European Commission titled “Back-Office Reorganization”. The goal of the study, carried out in cooperation with the Danish Technological Institute, was to collect and analyze good-practice cases of successful back-office integration for e-Government services for citizens and business. Altogether, 30 cases were identified and classified according to different integration requirements and solutions. The final report analyzed success factors and summarized lessons learned (Millard et al. 2004). In order to learn from the good-practice examples, a common platform on the Internet was launched in June 2005 and relaunched as the e-practice portal (http://epractice.eu) in June 2007. The most interesting finding was that there is no champion among the Member States showing a high degree of integration for most of the 20 reference services; rather, each country was advanced in some areas while lagging behind in others. The good-practice strategy may provide motivation, but it does not provide information about how individual progress has been achieved in successful cases, nor
1.6 Interoperability Strategies of the European Commission
9
does it take into consideration the great legal and cultural differences between the Member States, which could make replication difficult. While the Good Practice Strategy was developed by the Information Society and Media Directorate General (DG INFSO) within the Commission and employs the typical instruments of communications, funding of research, awards etc., the complementary Framework Strategy emerged in the DG Informatics, the former internal IT department of the Commission and therefore is much more technologycentered and more practically oriented. A first program (IDA I) had been started already in 1995, dedicated to the establishment of large telematics networks in the areas of employment, health, agriculture, statistics and competition (EC 1995). As these programs are always installed and funded for 5 years, in 1999 the follow-up program Electronic Interchange of Data between Administration (IDA II) was launched, still focusing on telematics networks, this time in the area of community policies such as the Economic and Monitoring Union (EMU) and aiming at interoperability between the telematics networks in the Member States and between the Commission and the Member States (EU 1999a, b). In 2004, the IDABC Programme has been launched for the period 2005–2009 (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens) with three goals: (1) promote interoperability of pan-European services, (2) conduct several studies, and (3) develop a European Interoperability Framework (EIF) to provide some guidance on how to progress with interoperability (EU 2004). In 2010, the follow-up program ISA (Interoperability Solutions for European Public Administrations) has been enacted for the period 2010–2015, focusing on common frameworks in support of interoperability, reusable generic tools and common services of generic nature, based on the Commission’s Communication “Towards Interoperability for European Public Services” (CEC 2010a) as part of the Digital Agenda and explicitly making reference to the European Interoperability Framework 2.0 (EIF 2.0). The Framework Strategy, which emerged out of a telematics context addresses the Chief Information Officers (CIOs) in the Member States and tries to provide in particular guidance for the selection of technical standards. However, with each generation the scope of application has been broadened and become more universal. At the same time, based on experience, the factors to be considered and mentioned in the frameworks have been extended far beyond technical standards and now include organizational, legal and even cultural issues. Despite all these efforts, interoperability in European public administration is far from being the rule is still confined to certain domains of application and not completely adhered to be all Member States: Towards the end of the first decade of the twenty-first century, however, few additional services on the common list were completely available online. • Similarly, in law enforcement, particularly across borders within the European Union, although legal provisions for information sharing exist, technical and organizational barriers prevent adequate exchange of information.
10
1 Introduction
• Many governments in Europe have recently declared a move towards more open government to increase transparency and allow for more participation. This requires easy access to government data across organizational boundaries. • Considering the early attempts to anchor interoperability of information and communication technologies (ICT) in the public sector, this was and still is an important aspect in public procurement. • Taking into consideration the large public budget deficits, we can expect a growing need for improvement in the efficiency of public administration. The pressure for organizational reform and for a networked type of government, however, is already increasing because of the demand for sharing resources.
1.7
The Need for Standardization and the Role of Interoperability Frameworks
In all three examples of back-office reorganization, presented above, standards for data exchange and coordination of workflows between different public agencies had to be developed. But as already mentioned, the examples show some differences. In the Irish case, a workflow along a supply chain of four agencies had to be defined, whereas in the Spanish tax case, a data exchange format for the entry of data by different organizations into a central database had to be issued. In the case of the German civil registries, a data exchange format for the bilateral exchange between thousands of agencies of the same kind in different geographical areas had to be established. And defining a data set is just one challenge. For security reasons, certain standards for encryption may be necessary and/or data may only be transmitted via a virtual private network. Interoperability Frameworks (IFs) attempt to reduce the complexity of the requirements by structuring and classifying those issues, which have to be standardized in such a way that they can be dealt with separately. Most of them apply a multi-layer model distinguishing between technical, semantic and organizational interoperability. So far, little is known about how much guidance and help in comparing different options and promoting interoperation these frameworks actually provide. Putting the technical, semantic, and organizational requirements together in one framework is both important and helpful because too often stakeholders assume that the Internet, i.e., the Internet protocol, provides for interoperability. In reality, it only provides for interoperability for the routing and transport of bits, not for mutual understanding of the data transmitted, i.e., semantic interoperability, and even less for the coordination of workflows, i.e., organizational interoperability. Furthermore, the degree of guidance provided for each of these requirements varies considerably. For achieving technical interoperability, acknowledged standards exist, such as EDIFACT or XML for data exchange. For semantic interoperability
1.8 Progress with EIF 2.0?
11
recognized concepts and methods exist such as ontologies. Organizational interoperability, in contrast, seems to be a residual category without such standardizations. These different degrees of structuring at the three levels contrast with the relevance of each for achieving interoperation. If there is no coordination between different units’ workflows, no effective e-government service involving their collaboration can be constructed. If there is no agreement between the units involved about rules to adhere to, coordination between workflows will not occur. In other words, organizational interoperability both is the most critical and the least structured issue in this context. The main reason for a lack of interoperability in e-government is a lack of cooperation between public agencies, which itself is due to the characteristics of the public sector with its complex authority structure of sub-sectors and levels (local, regional/state, national) authorities, political influence by and on elected officials, lack of financial incentives and many more (see Perry and Rainey 1988 for a summary). But in addition with regard to organizational interoperability in e-government there is also a knowledge factor, which makes matters even more difficult. So far, engineers with computer science and other technical training have developed IFs, which were built from bottom up, i.e., anchored on established technical standards. When these were adopted, semantic challenges arose, which then were dealt with in other sub-domains of computer science and information systems research. Then, in order to implement these standards in interorganizational workflows or G2G-communication, additional technical and numerous nontechnical provisions had to be made which were subsumed under the broad heading of organizational interoperability. Organizational issues, however, are more complex and fuzzy than issues of technical data transmission because they involve human actors whose behavior cannot be predetermined like the flow of electronic signals. These issues, which so far are summarized under the label of organizational interoperability, are the subjects of several professional and scientific fields. The inter-organizational coordination of workflows is the subject of the interdisciplinary research field of inter-organizational information systems (IOS); in the e-government context, collaboration between governments on different levels is the subject of administrative and/or political studies, and legal restrictions that may be encountered require legal expertise. By integrating knowledge from these different research fields, IFs might be improved and thus providing better guidance for achieving progress in e-government through interoperability.
1.8
Progress with EIF 2.0?
As mentioned before, the European Council originally had agreed to put the 20 reference public services online in a bi-directional mode by the end of 2003. In 2002, the target date was reset to the end of 2004 (CEC 2002, p. 10). When in 2004 the target date was still missed, the Commission launched the EIF to accelerate
12
1 Introduction
progress. In 2008 the overall target was still not met, and the Commission published a revised version, the EIF 2.0, for public comments. It included a more differentiated generic model of public services, a number of principles, an extended layer model with the addition of a political and a legal layer on top of the organizational, semantic, and technical layer of interoperability. Most of the debate, however, centered on the extent to which open standards, rather than proprietary industry standards, were to be recommended for e-government. Finally, in December of 2010, EIF 2.0 was published together with interoperability guidelines as a component of the Digital Agenda for Europe. This is a remarkable difference compared to EIF 1.0, which was more or less a stand-alone document. Now EIF 2.0 is one element besides a European Interoperability Strategy (EIS) decided by the Council of Ministers of all Member States (CEC 2010a). Compared with EIF 1.0 (European Communities 2004) the importance of political, legal, and even cultural factors for achieving interoperability was emphasized more strongly in EIF 2.0; however, the recommendations provided were rather abstract and selective. The layer of organizational interoperability was still quite heterogeneous as of then including business process alignment, memoranda of understanding, and change management. Given the complex nature and authority structures in the public sector, the detailing of memoranda of understanding and change management in an interoperability framework might be considered too simplistic. The framework did not take into consideration that achieving interoperability required negotiations and collaboration between actual human actors from different sectors and levels of government, for which often no established structures and rules exist. Reorganizing back offices and striving for interoperability in order to improve public services not only faces the problems inherent in organizational change, but also the challenge of repurposing existing organizations or creating new ones. To some extent EIF 2.0 recognized these problems and introduced the term of “governance,” but unfortunately without explaining what was meant by the term in this context and how the governance challenge of interoperability in government could be met. As a result, it is our view that little progress has been made between EIF 1.0 and EIF 2.0 in guiding interoperability projects in government. The revised document recognizes that the full potential of ICT can only be exploited when combined with the reorganization of processes and structures, and also that achieving interoperability in government interacts with culture and traditions, individual hopes and fears, political power relations, and other “soft” factors. The framework enumerates important context-related issues, but the recommendations given do not adequately draw on the knowledge available nor do they provide additional insights from targeted research on these issues elaborated in the frameworks. This does not only hold true in this case but also in the cases of numerous National Interoperability Frameworks (NIFs) of the Member States and beyond as well as for similar documents such as Enterprise Architectures (EAs), which are sometimes recommended for achieving interoperability in the public sector. For making progress in structuring the field of organizational interoperability and gaining more clarity on the issue of governance, we believe a comprehensive interdisciplinary approach is required. This could be achieved through a top-down
1.9 Exploring Organizational Interoperability and Governance Bottom-Up
13
and theoretically anchored approach or by a bottom-up approach, which analyzes successful examples of interoperation. Scholl and Klischewski have undertaken a top-down approach with their article “E-government Integration and Interoperability” published in the International Journal of Public Administration in (2007). Their article primarily frames a research agenda, and their framework does not attempt to provide guidance for practitioners working towards interoperability.
1.9
Exploring Organizational Interoperability and Governance Bottom-Up
The opportunity for an experience-based bottom-up approach was provided when the first two authors of this report were part of another consortium carrying out a “Study on Interoperability at Local and Regional Level” within the MODINIS program of the European Commission together with the European Institute for Public Administration (EIPA) in Maastricht and the Center for Research on Technology Hellas (CERTH) in Thessaloniki. The Study provided an overview of the status of interoperability in government of Member States and hypotheses on critical success factors and barriers derived from a review of technical literature, good-practice cases, and stakeholder consultation in several workshops (Tambouris et al. 2007, see also Archmann and Kudlacek 2008). The first two authors were responsible for selecting and analyzing good-practice cases of interoperability in government. The analysis of success factors and barriers was provided by the Greek partners on the basis of the original case description template of the good-practice portal, which did not contain a more differentiated view on organizational issues. This was made possible by a research grant from the German Research Association (Deutsche Forschungsgemeinschaft), which funded the development of a more elaborated classification and a re-coding of the collected cases, including additional investigations when necessary. This book represents the final report for this particular research grant. The recent discussions about the concepts of “governance” and in particular “IT governance” provided the context, in which this empirical analysis was conducted aiming to address the issues, on which EIF 2.0 did not elaborate. The main objective of the research reported here is to clarify and re-conceptualize the layer of organizational interoperability in IFs, which is relatively fuzzy. The basic idea was to split this complex subject into three dimensions. Organizational interoperability in a narrow sense, similar to technical and semantic interoperability, shall be confined to standards and concepts dealing with the linkage of business processes and workflows and be called business process interoperability. All other organizational aspects are to be conceived of as cross-cutting dimensions, which could not be confined to one layer but rather refer to elements on all layers, dealing with the governance of selecting and combining these different technical standards. The layers of technical, semantic and business process interoperability refer to “what” has to be made interoperable, i.e., standardized. But there is also the
14
1 Introduction
actor-related question of “who” could select or develop and authorize these standards and “how” they are to be implemented. These two additional challenges might be summarized as two aspects of governance. While the available literature allows for defining general categories of areas and modes of governance, a knowledge gap still exists with regard to the concrete options for the “who” and the “how” questions. This might be healed, at least in part, by the empirical analyses of how these issues were handled in good-practice cases of achieving interoperability in egovernment.
1.10
Objectives of This Research
In the two studies mentioned, 120 good-practice cases were collected and analyzed with an institutional and an IT-service view. Several sub-dimensions were specified and coded, which allow for meaningful differentiation and show relevant options e-government officials might be choosing according to their objectives and the context, in which they are acting. Not all cases provided for complete coding, and therefore some had to be excluded from the final analysis. This report is based on 77 well-documented and completely coded cases. Different methods have been applied to assess the validity and reliability of the classification. By presenting the context, the procedure, and the final, extended classification of organizational issues and modes and ways of governance, this report aims at achieving three objectives: • To provide input for improving existing IFs at national and EU levels, • To improve guidance for government officials and CIOs about what needs to be considered and what the available options are, not only on a conceptual level but also referring to real cases where the different options were successful, • To strengthen the explanatory power of comparative research identifying different degrees of success and failure of different options in various contexts.
1.11
Outline of This Report
In Chap. 2 we will define interoperability in government in more detail, put it in the historical and political context, discuss different models, and present survey results on information needs of stakeholders regarding interoperability. Chapter 3 looks at interoperability frameworks, their structure, and their purposes on both European and national levels. In this chapter, we also discuss the controversial issue of open standards and present findings from a comparative survey of national interoperability frameworks (NIFs). We also present and elaborate on our criticism regarding the fuzziness of the concept of organizational interoperability and outline our idea for re-conceptualization of the concept.
1.11
Outline of This Report
15
In Chap. 4, the selection and classification of the 77 case studies is presented, followed by an analysis of different kinds of interoperability requirements in Chap. 5, which are derived from interdependencies among agencies and between workflows. Chapter 6 deals with wants and needs of main actors with regard to interoperability in a sub-sample of these cases. In Chap. 7, we look at the empirical relationship between the different layers of interoperability as employed in these cases. In Chaps. 8 and 9, we present our empirical findings regarding the proposed re-conceptualization of organizational interoperability and governance. While Chap. 8 is dedicated to how interoperation is provided, Chap. 9 deals with IT governance, i.e., issues of who possesses or gains the authority to negotiate interoperability standards. In Chap. 10 we summarize the lessons learned from the previous analyses in a seven-step roadmap to setting up interoperable e-government services. In Chap. 11 we will discuss the broader ideas when going beyond individual achievements of interoperability for dedicated services to building up facilities and capabilities for achieving interoperability in a generic way in any future e-government project. Finally, in Chap. 12 we draw some conclusions from the research undertaken and also point to some dangers, which may require limits to integration.
.
Chapter 2
Interoperability in Government
As shown in the introduction interoperability in government is a complex, multidimensional, and multi-disciplinary phenomenon. Focused on the technical side, in particular CIOs in national and regional governments appear to share an understanding of interoperability, in which IFs play a central role. In order to understand what today’s IFs are what they are it seems helpful to remember the historical background. We take a look at early reference models in the first section of this chapter. Then we discuss the concepts mentioned in the introduction and present more detailed definitions. To corroborate our thesis regarding the relevance of organizational interoperability in particular, we present data from a survey of information needs of stakeholders.
2.1
Historical Background
The phenomenon meant by the term “interoperability” is much older than the term itself. It became relevant because different programs needed to share data within or between organizations. As shown below, the initial terms used were integration, electronic data exchange (EDI), connectivity, and open system interconnection (OSI), among others. The term “interoperability” originally emerged in the military sector and became prominent in the private sector, where the exchange of data between businesses is a must in a market economy. In many countries there were early considerations and initiatives to allow for the exchange of data between different units of government as well. It has to be remembered that in the 1970s, it was not yet possible to exchange data between the mainframe computer by one vendor, e.g. International Business Machines (IBM), and a Bull or Siemens mainframe. E-Mails, i.e., office messages, could only be sent to other affiliations connected to the same mainframe computer and not beyond. There were dedicated fixed-line connections between mainframe computers and only a few dial-up connections, which required the same data transmission rate. When IBM introduced its System Network Architecture (SNA) allowing data exchange and the exchange H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_2, # Springer-Verlag Berlin Heidelberg 2011
17
18
2 Interoperability in Government
of messages between different computers of its mainframes for different customers, the open system interconnection model (OSI) was developed as a European Initiative to challenge the emerging IBM monopoly by open standards via the International Standards Organization (ISO). Early results of this era include 400 as an open standard for e-mails or 0.500 for directories (Genschel 1995, p. 114). Several state and regional governments developed dedicated networks for a secure exchange of data between units of state and local governments. Similar initiatives at the national level were not successful for many years, for both technical and political reasons. Taking a closer look at the historical background of today’s IFs helps to clarify why they are how they are.
2.1.1
The Emerging Need for Standards
The term “interoperability” was introduced by the US Department of Defence in a document called “Standardization and Interoperability of Weapon Systems and Equipment Within the North American Treaty Organization NATO” in 1977 (DODD 1977, see Charalabidis et al. 2011, p. 356). Here, interoperability was defined as The ability of systems, units or forces to provide services to and accept services from other systems, units, or forces and to use the services so exchanged to enable them to operate effectively together.
Outside the military sector and more directly related to ICT in Europe, the term became official in a European directive on software copyright and defined as “the ability to exchange information and mutually use the information, which has been exchanged” (EC 1991). In 1998, “interoperability” was mentioned in the European Standards Directive 98/34 EC (EU 1998) and, with regard to e-government, became a policy objective in the Lisbon Strategy of the European Union. The Lisbon Strategy then led to the eEurope 2002 and 2005 action plans, the follow-up plan i2010 and recently the digital agenda for Europe 2020 (CEC 2010b). According to the mandate of the European Commission to establish a common economic area, interoperability in this context is meant to allow for trans-border exchange of data within a common market and between units of government in different Member States. A precondition for data exchange between different computers is the compatibility of procedures or protocols, which control this exchange. In the early 1970s, IBM developed the Systems Network Architecture (SNA), a standard for the protocols for internal exchange between computers from different IBM product lines (see Genschel 1995, p. 114). Other vendors such as Honeywell and Sperry followed with similar standards. They did not, however, allow for any data exchange between computers of different organizations. When user companies considered this necessary, particular gateways had to be built for each single interconnection. Studies report that user companies at that time had to spend about 20% of their total IT
2.1 Historical Background
19
budget for these gateways, and up to 50% in the automobile industry (Genschel 1995, pp. 115f). Organizations that used proprietary computer networks put some pressure on computer vendors to make their products more compatible and to provide interconnectivity by standards. IBM, with the largest market share, saw the chance to introduce SNA as de facto industry standard and made its specifications publicly available. At the same time, in the United States, research work on the ARPANET had begun, which aimed to specify protocols. The APRANET protocols later became the Internet protocol. Similar activities were started in a European Research Programme. In Europe, however, some vendors and governments were concerned about the IBM strategy, fearing a de facto monopoly. In particular, the British Standards Institute tried to establish a working committee within the International Standards Organization (ISO) promoting an open communication architecture. In 1997, ISO TC97SC16 was established in order to develop a reference model for an open systems interconnection.
2.1.2
The OSI Reference Model
A reference model is no communication architecture specifying a set of protocols like SNA, but rather a meta-standard defining and classifying what has to be standardized. One of the main purposes of the OSI reference model was to allow for comparisons of the existing proprietary architectures. In addition, it needed to classify protocols and interfaces in such a way that they still interoperate while different working groups continued to specify them. For this purpose, an onion- or multi-layer structure was chosen. In 1979, the first draft of a seven-layer reference model was presented. In 1983, after several revisions, the Open System Interconnection Basic Reference Model was issued as ISO Standards 7498 (Genschel 1995, p. 117 with more references). A “layer” is a class of similar functions that provides a particular service to the layer above it and that receives services from the layer below it. Figure 2.1 depicts the structure of the model. Application process 1 starts on layer 7, the application layer which builds on particular services provided by the six layers below. Data are transmitted physically via a connection according to standards on layer 1, received by the same layer 1 of System 2, and provided for Application Process n by services according to layers 2–6. Table 2.1 shows a definition of the service provided by each layer and some of the standards or protocols assigned to that layer. The term “application layer” is misleading because that layer does not refer to an application in the sense of, for example, a public e-government service, but only to network services provided for an application. An example, the file-transfer protocol (FTP) as well as the hypertext-transport protocol (HTTP) are associated with this layer. It does not specify anything regarding the kind of data interchanged via FTP or HTTP, nor regarding the kind of business processes or workflows involved.
20
2 Interoperability in Government
Fig. 2.1 OSI reference model Table 2.1 Layers of the OSI reference model and standards assigned Layer no Layer type Layer definition Protocol examples Layer 7 Application Network process to application DNS, FTP, Gopher, layer HTTP, SMTP, DHCP Telnet Layer 6 Presentation Data representation, encryption and MIME, SSL layer decryption, convert machine dependent data to machine independent data Layer 5 Session Interhost communication Named Pipes, NetBIOS, layer SAP Layer 4 Transport End-to-end connections and reliability, TCP, UDP, DCCP, SPX layer flow control Layer 3 Network Path determination and logical P (IPv4, IPv6) AppleTalk layer addressing Layer 2 Data link Physical addressing ATM, SDLC, HDLC, layer Frame Relay, X.25 Layer 1 Physical Physical media, signal and binary DSL, IEEE 802.3, USB, layer transmission Bluetooth
In other words, application systems, such as invoicing or registration processes, are neither subject of nor within the domain of the OSI reference model. Because organizations that use computer-based networks were in need to exchange data such as orders, invoices, and construction data, they wanted the
2.1 Historical Background
21
ability to exchange data electronically between corresponding applications in a way that new suppliers or customers could easily join in. These organizations needed and wanted standards for data interchange. Electronic data interchange (EDI) can be defined as computer-to-computer interchange of strictly formatted messages by agreed message standards without human intervention (Benjamin et al. 1990; Kimberley 1991; Kubicek 1993). The OSI standards provided but insufficient specifications in this regard, since syntaxes and semantics of data exchanged also had to be standardized. In major industries such as automobiles or banking, industry associations developed proprietary data exchange formats: ODETTE for the automobile industry and SWIFT for interbank exchange of messages for electronic funds transfer (Fig. 2.2). In the United States, the National Standards Institute issued ANSI ASC 12; in Europe, the UN-recommended UN/EDIFACT is predominant. In 1987, the United Nations/Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) was developed under the guidance of the UN Economic Commission for Europe (UN/ECE) as a set of cross-sector standards for messages such as orders and invoices. Today, UN/CEFACT administers more than 200 message types (United Nations Centre for Trade Facilitation and Electronic Business). EDIFACT is a language to define messages according to a common syntax that provides rules such as how the header of a message is to be separated from the message body, and how data fields have to be separated. A particular message type, e.g., an order, specifies the meaning of the different fields such as name and
Fig. 2.2 Extended layer model of EDI
22
2 Interoperability in Government
identifier (ID) of the ordering company, date of order, or the goods ordered. The syntax does not, however, include the meaning of the data within each field defined, i.e., the ID of the ordering company or the goods ordered. For this purpose, common codes are needed, such as the European Article Number (EAN) or the Universal Product Code (UPC). To achieve automatic processing of these messages, respective codes for each data field must be agreed upon, and a common understanding of the workflows on the side of the receiving organization by the sending organization must be established. In inter-business EDI, the exchange usually takes place under a contractual agreement between trading partners (Benjamin et al. 1990; Kimberley 1991; Kubicek 1993). In the public sector, the need for EDI was not as strong. For connecting government agencies, separate dedicated networks were first established at the national level to interconnect national agencies that had different protocols. The Internet Protocol enabled connectivity, but different provisions were taken at different levels of government for additional security requirements. With regard to applications and data exchange formats, a distinction between business-to-government/ government-to-business (B2G/G2B) communication and government-to-government (G2G) communication had to be made. In the area of G2B communication and public procurement, in particular, some countries made electronic submission of bids and/or invoices mandatory, while other countries such as Germany maintained quite different provisions on State and local government levels. With regard to G2G communication, EDI varies to a large extent between services throughout EU Member States. To improve interoperability for cross-border procurement, the European Commission funds Large-Scale Pilots where a larger number of Member States establishes interoperation between their national systems (for e-procurement see PEPPOL at http://www.peppol.eu). However, in practice across all Member States differences regarding the mutual recognition of digital signatures despite a binding European Directive remain and limit the Single European Market (Cimander et al. 2009).
2.2
Definitions
Interoperability of ICT systems is not a new issue in computer science and practice. In that context interoperability has been defined as “{t}he ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE 1990). But the definitions have been extended along various dimensions in the years since the term was first defined (see box). European Public Administration Network E-Government Working Group (EPAN) Interoperability is the ability of a system or process to use information and/or functionality of another system or process by adhering to common standards. An “interoperability architecture” is made up of a range of complementary technical specifications, systems, standards, guidelines and polices. There are five interlinked layers in an interoperability architecture as set out at Figure A with specific principles at each layer (EPAN 2004). (continued)
2.2 Definitions
23
In telecommunication the European Telecommunications Standards Institute (ETSI) writes: There is no single definition of the word interoperability: even at ETSI the term has different meanings in different contexts (see, for example, the Terms and Definitions database at http://webapp.etsi.org/Teddi/). However, the following definitions are probably the closest to a common understanding within the ETSI community: Interoperability is the ability of two systems to interoperate using the same communication protocol” from ETSI Project TIPHON (now closed). Or the definition of interoperability of Next Generation Networks (NGN) from ETSI’s Technical Committee TISPAN: “Interoperability is the ability of equipment from different manufacturers (or different systems) to communicate together on the same infrastructure (same system), or on another while roaming.” Or in the context of the third Generation Partnership Project, 3GPP1: “the ability of two or more systems or components to exchange data and use information” (ETSI 2006, p. 5). “With respect to software, the term interoperability is also used to describe the capability of different programs to read and write the same file formats and utilize the same protocols. Interoperability can have important economic consequences, such as network externalities. If competitors’ products are not interoperable (due to causes such as patents, trade secrets or coordination failures), the result may well be monopoly or market failure. For this reason, it may be prudent for governments to take steps to encourage interoperability in various situations. According to ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms, interoperability is defined as follows: “The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units”.” (ISO/IEC 1993). The recent decision by the European Parliament and the Council establishing the ISA program (Interoperability Solutions for Public Administration) of September 2009 as well as EIF 2.0 define interoperability as follows: “‘Interoperability’ means the ability of disparate and diverse organizations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between organizations, through the business process they support, by means of data between their respective ICT systems” (EU 2009, p. 23).
In a staff document, The European Commission defined the term in more detail: “Interoperability is like a chain that allows information and computer systems to be joined up both within organizations and then across organizational boundaries with other organizations, administrations, enterprises or citizens. It has three aspects: • Technical interoperability, which is concerned with the technical issues of linking up computer systems, the definition of open interfaces, data formats and protocols, including telecommunications; • Semantic interoperability, which is concerned with ensuring that the precise meaning of exchanged information is understandable by any other application not initially developed for this purpose; and • Organizational interoperability, which is concerned with modeling business processes, aligning information architectures with organizational goals and helping business processes to co-operate” (CEC 2003).
24
2 Interoperability in Government
Reference to these three kinds of interoperability is common to almost all definitions. However ETSI introduces a further distinction between technical and syntactic interoperability: • Technical Interoperability is usually associated with hardware/software components, systems, and platforms that enable machine-to-machine communication to take place. This kind of interoperability is often centered on (communication) protocols and on the infrastructure needed for those protocols to interoperate. • Syntactic Interoperability is usually associated with data formats. Messages transferred via communication protocols need to have a well-defined syntax and encoding, even if only in the form of bit tables. However, many protocols carry data or content, and this can be represented using high-level transfer syntaxes such as HTML, XML or ASN.12“(ETSI 2006, p. 5) Some variance also appears in regard to additional aspects, such as political or legal issues (see Charalabidis et al. 2011 and Chaps. 3 and 7 in this book). For some kinds of interoperability there are also other terms in use: • Technical interoperability is sometimes called compatibility. Hardware or software compatibility most often refers to software running on different hardware and operating systems, but it also refers to connectivity with network facilities. • Semantic aspects play a major role particularly in service integration and information sharing. In the broadest sense, the term integration means to unite something with something else or to coordinate parts into a functioning unified whole. It refers to technical and non-technical aspects, i.e., when information systems of previously separated systems are integrated into a new unified system and when previously separated workflows are integrated into one larger business process. Klischewski (2004) describes information integration as “exchange of information as shared resource” and process integration as “coordination of contributions to overarching process.” • Finally, alternative terms for organizational interoperability are “collaboration,” “cooperation,” or “coordination.” These terms refer to rules and regulations regarding workflows, duties and liability, cost sharing, and other issues that form the context, in which technical and semantic interoperability is established. Scholl and Klischewski make another relevant point. Interoperability, as the last seven letters of the term depict, refers to ability. Therefore they define interoperability as “the technical capability for e-government interoperation,” which “occurs, whenever independent or heterogeneous information systems or their components controlled by different jurisdictions/administrations or by external partners smoothly and effectively work together in a predefined and agreed upon fashion” (Scholl and Klischewski 2007, p. 900). Pardo, Nam and Burke emphasize that interoperability is not an end itself but a means to an end, i.e., better government services to citizens and business. Based on numerous references they illustrate that recent perspectives recognize that interoperability is more than a technical capability including policy and management
2.3 Governance and IT-Governance
25
capabilities in order to “connect governments across boundaries to share information and integrate service delivery.” Interoperability is seen as a multi-dimensional phenomenon building on at least four strands of academic and practitioner-focused literature: enterprise architecture, capability maturity, information system and information sharing (Pardo et al. 2011, p. 2). We may want to add strands of organization theory, in particular the strategic choice between centralization and standardization. With regard to the political dimension frequently reference is made to the concept of “governance.”
2.3 2.3.1
Governance and IT-Governance Two Contexts and Meanings of Governance
The term “governance” is used in two different contexts with different meanings. There is a discussion on “good governance”, dealing with ethical codes for government and corporate leaders and management. Definitions, which serve as practical yardsticks for compliance reviews as well, are provided by the World Bank (1993), the United Nations Development Programme (UNDP) (1997) and the European Commission (2001) and include criteria such as efficiency and effectiveness, transparency, accountability among others. In contrast to this normative use, there is a descriptive meaning, distinguishing different modes and ways of how a society, a sector of society or a group of organizations can be directed or coordinated towards a certain goal. German political scientist Renate Mayntz offers the broadest definition: “Governance is the totality of all co-existing forms of collective coordination of social issues from institutional societal self-regulation via several forms of cooperation between governmental and private actors to official duties of state actors” (Mayntz 2004, p. 66, translated by Meuleman 2008, p. 11). Similarly, Hirst asserts that “governance can generally be defined as the means by which an activity or ensemble of activities is controlled or directed such that it delivers an acceptable range of outcomes according to some established standard” (Hirst 2000, p. 24). According to Lynn Jr., Heinrich, and Hill, governance “refers to the means for achieving direction, control and coordination of wholly or partially autonomous individuals or organizations on behalf of interests to which they jointly contribute” (2000, p. 235). With regard to public policies and their implementation, they propose to define governance “as regimes of laws, administrative rules, judicial rulings, and practices that constrain, prescribe and enable government activity, where such activity is broadly defined as the production and delivery of publicly supported goods and services” (Lynn et al. 2000, p. 235). A central question of public governance research is concerned with how governance regimes dispersed across offices, municipalities and states can be “induced to converge on the achievement of particular policy objectives” (Lynn et al. 2000,
26
2 Interoperability in Government
p. 235). Lynn Jr. et al. emphasize that public sector governance is “inherently political, involving bargaining and compromises, winners and losers” because it distributes responsibility and resources “for functions and operations within and between offices and organizations in the public and private sector” (Lynn et al. 2000, p. 235). For analyzing governance configurations in the public sector they recommend an institutional perspective, according to which legislators in responding to citizen and stakeholder interests create coalitions to enact certain bills to create arrangements, which in turn empower or restrict the discretion of certain agencies or establish new ones (Lynn et al. 2000, p. 238). In other words, public governance defines the discretion of public management. This may apply to all kinds of policy fields and also to e-government policy. As e-government deals with the use of ICT, it is worthwhile to look at a special strand of literature dealing with IT governance.
2.3.2
IT Governance
In the ICT context, the term IT Governance often supplements or even substitutes for the term IT Management. The IT Governance Institute (ITGI) has developed the Control Objectives for Information and Related Technology Framework (COBIT) which defines IT governance as “a structure of relationships and processes to direct and control the enterprise in order to achieve the enterprise’s goals by adding value while balancing risk versus return over IT and its processes” (ITGI 2000, p. 5). In academia, IT governance is defined as “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT” (Weill and Ross 2004, p. 8) or as “the leadership and organizational structures, processes and relational mechanisms that ensure that an organization’s IT sustains and extends its strategy and objectives” (Van Grembergen et al. 2004). It shall bridge the gap between technically centered IT management and top management as well as between ICT-related investment and corporate objectives. One might even say that it is an attempt to overcome the distrust boards of directors have with regard to their CIOs. Weill and Ross have identified five majors decision domains and six different archetypical approaches to IT decision making from highly centralized to highly decentralized. The domains of IT governance cover IT principles, IT architecture, IT infrastructure, business application needs and prioritization and investment decisions. These decisions may be taken within a business monarchy, an IT monarchy, a federal system, an IT duopoly, a feudal system, or anarchy (Weill and Ross 2005, p. 27). These decision domains and organizational structures are also subject of IT management. Therefore it is not clear what the difference between IT governance and IT management is. More importantly, the literature on IT Governance primarily deals with the coordination and control within a single organization, at most within an enterprise composed of several legally autonomous companies under the control
2.3 Governance and IT-Governance
27
of one headquarters. The literature rarely, if ever, addresses the coordination of ITrelated activities in collaborative and cooperative settings of independent entities such as joint ventures or purpose-focused cooperation such as in procurement or distribution activities. These issues are subjects of the research field of InterOrganizational Information Systems (IOS) (Cash 1985; Kubicek 1992; Homburg 1999; Chatterjee and Ravichandran 2004; Reimers et al. 2008) or the theories of strategic networks (Sydow 1992; Jarillo 1995).
2.3.3
The Public-Private-Distinction
One may discuss to what extent structures and processes of intra-organizational IT governance or IT management in the private sector do apply to and are appropriate for public sector organizations in the light of the general debate on the PublicPrivate-Distinction (Rainey et al. 1976; Perry and Rainey 1988). In both a private enterprise and an agency on any level of government one can find a CIO, an official IT strategy, an IT steering committee, service level agreements, monitoring and measurement maturity models, and other procedures. A federal CIO located in a ministry may have less formal authority to set IT standards or take investment decisions vis-a`-vis other ministries than a corporate CIO who might even be a member of the board of directors. And national/federal CIOs have only very limited authority vis-a`-vis regional or local governments. But in practice many corporate CIOs also have only limited powers to exercise a central IT management. With regard to inter-organizational cooperation and IT-related decisions major differences can be found between networks of enterprises and networks of government agencies, in particular, if these agencies belong to different levels of government and to different legislative domains. Therefore we squarely doubt that the enterprise metaphor as applied in the general IT Governance literature can serve as a viable paradigm for the governance of interoperability in government. In our view, it appears highly problematic and misdirected for the public sector. We propose to take a broader view and adopt the governance definition by Lynn Jr., Heinrich and Hill, quoted before, referring to the regimes which constrain, prescribe or enable government activities and distinguish between activities related to the cooperation with regard to public services and those activities concerning the cooperation in IT-deployment interoperability and online services. Following their basic institutional model we can assume that political coalitions will always form for reforming or innovating a public service and assign the authority for planning the respective IT support to either existing or new agencies. In other words, publicsector governance of public services sets the stage for public-sector IT governance, in particular, the governance of interoperability in government. Different forms of governance of interoperability can be distinguished along the centralized/decentralized dimension proposed by Weill and Ross (2005) or following the concepts of institutional theory, referring to the three basic models of institutional theory in economics (see Meuleman 2008 for extensive references):
28
2 Interoperability in Government
• Hierarchies, • Markets, • Networks. These basic forms of institutions can be found at the societal level as well as with regard to the governance of public services and IT deployment: • Hierarchy refers to a centralization of planning authority and/or operating tasks; • Networks, sometimes also called federations, include various kinds of settings where agencies negotiate rules to be shared and reach agreement; • Markets refer to a situation, in which, for example, the operation of certain services is assigned to contractors or service providers via public procurement.
2.4
Integration, Centralization and Standardization: Technical and Organizational Issues
In the 1970s, Child identified a strategic choice between centralization and standardization for intra-organizational coordination (Child 1972a, b) building on earlier work of Cyert and March (1963). In their behavioral theory of the firm the two authors had identified standard operating procedures as an alternative coordination mechanism to hierarchical orders. Kubicek and Cimander (2009) have proposed to distinguish organizational models of providing for interoperability along these two dimensions. Scholl and Klischewski (2007) point out that exchange of information between agencies always encompasses both the technical and the organizational dimension and suggest using the term “integration” for the organizational dimension and “interoperation” for the technical dimension. Reviewing the literature, we find that some authors use these terms for technical issues and others for organizational issues. Integration not only refers to the merging of formerly separated organizations or organizational units, as Scholl and Klischewski use the term (2007, p. 897), but also to the technical integration of databases and workflows. The term “integrated data processing” is well established in computer science. Similarly, centralization refers to the centralization of formerly separated databases as well as to a centralization of tasks and agencies. The term “standardization” is not only used with regard to technical standards allowing compatibility of products or processes but, as mentioned above, also to denote a coordination mechanism in the form of standard operating procedures and formal directives within organizations. Since we cannot reserve the terms integration, centralization, and standardization for technical or organizational issues exclusively without colliding with the terminology of other scholars or stakeholders, we will add the adjective “technical” or “organizational” wherever appropriate. Connecting with the basic forms of governance, mentioned above, we may conceive the strategy or organizational model of centralization as governance by
2.5 Stakeholders’ Information Needs
29
hierarchy, i.e., by establishing a formal structure of authority where one higher level unit has the authority to plan for an integrated ICT system to support one or several public services. The alternative form of governance is a network model, which according to Scholl and Klischewski may be called a “federation”, denoting interaction “in a formal contractual agreement over tightly merging processes and/or over methods and formats of sharing information of guaranteed highest quality” or more loosely forms of working groups (Scholl and Klischewski 2007, p. 898). Such a federation negotiates and hopefully agrees to the use of certain technical standards in order to achieve interoperation. The basic strategic choice for achieving interoperation between previously separated units or agencies before this background can be described as follows: • Formerly separated databases and/or workflows can be technically integrated leading to a new central database and/or technically integrated business process. Integrating the organizational rules and assigning authority to an organizational unit, which integrates the formerly separated functions but not necessarily jobs and people, achieves this. In any case, formerly decentralized distribution of authority is centralized. • Alternatively, the separate technical systems and the decentralized organizational distribution of authority can continue while still achieving interoperation when the separate technical systems deploy common interfaces and common standards for syntactic, semantic, and process-related features of data exchange, agreed upon by contracts between the agencies concerned, i.e., by establishing a federated network structure.
2.5
Stakeholders’ Information Needs
In academic articles (e.g., Scholl and Klischewski 2007; Pardo et al. 2011) as well as in recent policy statements (CEC 2010a) we found strong consensus to the extent that interoperability in government is about more than just technology, and that it rather also involves organizational, legal, cultural and policy issues. If IFs are to provide guidance to government stakeholders in order to achieve interoperation of public electronic services, at a minimum they need to meet the information needs of their target groups. Within the above-mentioned MODINIS Study on Interoperability at Local and Regional Level, a survey on these information needs was conducted by the first two authors of this report in 2005 in order to provide some guidance for the selection of good-practice cases and to surface the emphases given to issues addressed in the case descriptions (see Kubicek and Cimander 2005 for more details). Stakeholders from then 25+ EU Member States with an interest in interoperability in e-government were selected to participate in the survey via nomination by national e-government representatives in working groups of the EU Commission, or drawn from existing networks. Altogether 67 experts completed the questionnaire. Table 2.2 shows experts’ affiliations.
30
2 Interoperability in Government
Table 2.2 Participants in survey on information needs
Local and regional government National government IT-business Academia
20 27 10 10
First of all, stakeholders were asked what kind of interoperability requirements they would like to be dealt with in case collection and analysis. For this purpose, a distinction was made between interoperability requirements resulting from • • • • •
Data sharing by different authorities, Data sharing between the same authorities, Connecting different stages of a service provided by different authorities, Integrating different auxiliary services into one or more primary services, Providing common repositories, metadata, etc., to one or more public services.
Respondents could assess the strength of their interest by putting these items in to a ranking order, assigning rank 1 to the item of highest interest. For comparison we have only counted how often an item was placed on rank 1 or 2. Table 2.4 shows these frequencies of the highest ranked options for the whole sample and for respondents mean values for the whole sample of stakeholders as well as for stakeholders coming from countries of different sizes. One has to keep in mind that population size in EU Member States varies between 0.4 and 82 million people. Therefore, we distinguished three size classes of Member States representing different degrees of complexity for achieving interoperability: • Large Member States: more than 30 million inhabitants (up to 82.5 million), • Medium-sized Member States: 7.5–30 million inhabitants, • Small Member States: less than 7.5 million inhabitants. In the overall ranking, Table 2.3 shows that highest interest was placed on interoperability between different stages of a public service provided by different authorities. This held also true for large and small countries. In contrast, stakeholders from medium-sized countries gave a slightly higher priority to data sharing by different authorities and common repositories. Stakeholders from all levels of Government also show the greatest interest in cases of interoperability between different stages of a service, while stakeholders from IT business and academia have no common priorities. In addition, stakeholders were asked what kind of government authorities they would like to see in the cases where interoperability has been achieved. Table 2.4 shows that interest in intra-organizational interoperability was low. We distinguish between interoperability requirements at the same level of government (national or state/regional), i.e., horizontal interoperability, on the one hand, and between agencies at different levels (vertical interoperability requirement), on the other hand. Respondents showed medium strong interest in both areas; highest priority was given to cases where horizontal and vertical interoperability requirements were mixed.
2.5 Stakeholders’ Information Needs
31
Table 2.3 Information needs regarding interoperability requirements Country size Stakeholder group
Projects aiming at data sharing by different authorities Projects aiming at data sharing by same authorities in different areas (or regions) Projects where interoperability is achieved between different stages of a service that involve different authorities Projects where auxiliary services (e.g. payment, authentication) are integrated that are common to many authorities Projects where the aim is to build common repositories of services, meta data, directories, etc.
Big Mid Small Loc/reg. Nat. gov. IT-bus n All (23) (30) (13) gov. (20) (27) (9) 62 17 8 7 2 8 6 2
Acad (10) 1
54
6
5
1
0
3
1
2
0
61 24 11
6
7
10
10
1
3
58
8
1
6
1
2
3
2
1
60 15
4
9
2
5
6
1
3
Table 2.4 Information needs regarding agencies concerned Country size Stakeholder group
No integration, we are interested in projects within one authority Between authorities at different levels of government (vertical) Between authorities at the same level of government (horizontal) Mixed vertical and horizontal Between authorities at different countries
Large Mid n All (23) (30) 33 1 0 1
54 14
Small Loc/reg. (13) gov. (20) 0 0
Nat. gov. IT-bus (27) (9) 0 1
Acad (10) 0
7
6
1
9
4
1
0
56 15 10
5
0
6
3
4
2
63 34
8
16
10
10
19
2
3
54 15
4
9
2
2
3
5
5
32
2 Interoperability in Government
This situation is the most complex and therefore has the strongest information needs. Only in large Member States we found a slightly higher interest in cases of horizontal interoperability. Because of their size, these states have a higher division of labor and greater differentiation of government authorities at the national level, making interoperability more difficult. Stakeholders from national governments clearly showed greater interest in mixed requirements as there are almost no public services to citizens on the national level, authorities from regional or local levels have to be included. In contrast, stakeholders from local or regional levels were interested in vertical interoperability requirements. Respondents from IT business and from academia were also interested in pan-European cases, which did not rank very high for government representatives because at that time there was still little demand. Based on the assumption that stakeholders had some clear idea of how to establish interoperation, the survey asked them to specify, which kind of organizational model they wanted to learn more about. Table 2.5 demonstrates that the greatest interest was in direct bi- or multi-lateral exchanges of data. Only stakeholders from small countries did not show clear preferences. It is interesting to see that stakeholders from IT business were equally interested in central provisions and clearing houses but not so much in direct bi-lateral data exchange which requires less investment in equipment. Respondents were also asked which different kinds or layers of interoperability they would like to learn more about. The overall frequencies showed a clear priority for semantic interoperability, followed by organizational interoperability, Table 2.5 Information needs regarding organizational model Country size Stakeholder group n
Large Mid Small Loc/reg. Nat. gov. IT-bus Acad All (23) (30) (13) gov. (20) (27) (9) (10)
Direct bi-lateral or 59 28 11 direct multi-lateral communication between authorities according to standardized interfaces and procedures A central unit which 64 21 6 defines the protocols and procedures for communication with many local units A clearing house (or 57 21 9 broker or intermediary) which transforms and adapts different formats and procedures between the units involved
12
5
12
9
1
6
10
5
6
9
4
2
7
5
3
11
5
2
2.5 Stakeholders’ Information Needs
33
and much less for technical interoperability. The significance of this rank order increases with big and medium-sized countries. Only more stakeholders from small Member States showed the highest interest in technical interoperability. This difference may be explained by the informed assumption that smaller Member States did not have their own networks or were interested in improving the security of data transmission. The majority of almost all stakeholder groups gave highest priority to semantic interoperability, closely followed by organizational interoperability. Only among stakeholders from national government and from academia, more respondents gave higher priority to organizational issues (Table 2.6). Table 2.6 Information needs regarding layer of interoperability (IOP) Country size Stakeholder group Mid (31)
Small (13)
66 29 12
13
4
9
12
2
6
64 29 12
14
3
11
10
5
3
7
6
4
8
3
1
n Organizational IOP e.g. processes that should be changed or adapted or improved, etc. Semantic IOP e.g. agreement on common formats on data exchanges, etc. Technical IOP e.g. technologies available, technical standards, etc.
Big All (23)
61 16
3
Loc./reg. Nat. gov. IT-bus. Acad gov. (20) (27) (10) (10)
Notably, fewer stakeholders from IT industry (2 out of 10) and from small countries (4 out of 13) ranked organizational interoperability high. In small countries, a higher degree of centralization decreased concern for linking business processes. ICT industry sells products for technical and semantic interoperability, but there was and still is only a small market for products providing for organizational interoperability existed. Finally respondents were asked which factors they considered crucial for the success of interoperability projects and which they would like to learn more about. In the overall figures security issues most frequently were given highest priority, followed by legal issues. For stakeholders from small countries or from national governments it was the other way round. Six of ten stakeholders from IT business showed the highest interest in security issues and only one respondents in this group ranked legal, cultural or social issues higher (see Table 2.7). The low priority given to cultural aspects is remarkable in light of recent discussions on barriers and success factors for interoperability. In the social and political science strand of e-government research, the consensus is that cultural factors are most crucial. They are even decisive for legal reforms and for the
34
2 Interoperability in Government
Table 2.7 Information needs regarding relevant factors Country size
Legal, e.g. changes in laws, regulations, etc. Cultural, e.g. resistance from public servants, etc. Social, e.g. social inclusion, etc. Security, e.g. signatures, encryptions, etc.
Stakeholder group
Large Mid Small Loc/reg. Nat. gov. IT-bus Acad n All (23) (31) (13) gov. (20) (27) (10) (10) 64 19 7 6 6 4 13 1 1
57 15 6
7
2
6
4
1
4
55
8 5
3
0
5
2
0
1
59 24 6
14
4
8
9
6
1
acceptance of IT security factors. The Center for Technology in Government (CTG) accordingly stressed the need for cultural change by building up capabilities in cultural and social capital (see Pardo et al. 2011). Even official documents of the European Commission emphasize that interoperability has to do with cultural values and skills. To summarize, this survey corroborates the assumption in academic literature and political statements that organizational interoperability is recognized as a critically important element and that stakeholders involved in interoperability projects are interested in learning more about these issues. In particular, they are interested in how interoperability is established in cases when different agencies on different levels of government have to cooperate. Many stakeholders have a preference for establishing interoperability via direct data exchanges between the units involved, fewer stakeholders showed interest in the involvement of clearing centers and other intermediaries. We will have to check whether this is reproduced in our collection of good practice cases. The low frequencies of interest in legal, cultural, and social factors in this survey do not necessarily mean that these factors are less important for the success of interoperability projects. Rather this outcome may have resulted from the selection of respondents. It was not surprising that stakeholders from the IT industry were mostly interested in the technical aspects and security issues and less in organizational and cultural aspects because there are no respective products on their shelves. It is more surprising that also stakeholders from all government levels show great interest in technical aspects. This may be due to the fact that many of the participants in this survey were IT experts, in charge of interoperability projects, and therefore interested in learning more about this field. They may know or feel that soft factors are influencing the deliverables in their projects and that legal and cultural change is required for successful implementation. From a pragmatic point of view, however, no measures appear to exist for creating a favorable culture or for securing support from all stakeholders involved. By adopting a case study approach, however, we were able to describe in-depth good-practice examples of how these soft factors could be handled within different settings and under different circumstances.
Chapter 3
Review of Prominent IFs and the Need for Re-conceptualization
Interoperability of ICT systems presents a complex, fuzzy, multi-dimensional, and multi-disciplinary phenomenon. So, some structuring of perspectives appears to be necessary to reduce the phenomenon’s complexity. While we propose to distinguish differing perspectives, we also propose that some perspectives might be complementary. Interoperability frameworks (IFs), which are developed for different domains such as business, the health sector, and e-government, can help understand the phenomenon from its various angles. The first IFs were developed in the military domain. IFs for e-government are usually issued by national governments. The first National Interoperability Framework (NIF) was the UK government’s e-Government Interoperability Framework (e-Gif), issued in 2000, which prescribes the policies and technical specifications that will serve as the foundation of the UK’s e-government strategy (Guijarro 2010, p. 284, see http://interim.cabinetoffice.gov.uk/govtalk/schemasstandards/e-gif.aspx). Several other Member States followed. In 2004 the European Commission had launched a European Interoperability Framework (EIF) which was to support the interoperability of pan-European public services and provide some guidance for the NIFs of the Member States. While EIF 1.0 was issued as a recommendation to Member States by DG Informatics, EIF 2.0, as mentioned before, is part of the Digital Agenda for Europe, together with a European Interoperability Strategy (EIS). In 2010 followed EIF 2.0. It is of greater relevance for national e-government activities of the Member States because it is the subject of a formal Communication of the Commission and not only a single DG. In addition, a working group of Chief Information Officers of the Member States have committed themselves to considering these recommendations both in developing their own NIFs and when planning national public services. In the future, interoperability on the national level will likely become even more important and will increasingly have to be considered with respect to its European dimension. Therefore, the EIF and related initiatives and documents will become more relevant for the e-government development in each Member States.
H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_3, # Springer-Verlag Berlin Heidelberg 2011
35
36
3 Review of Prominent IFs and the Need for Re-conceptualization
EIF 2.0 takes a broader view than EIF 1.0 adding an additional layer of legal interoperability and emphasizing the significance of governance. Nevertheless, EIF 2.0 is still not entirely clear about these issues. A striking mismatch remains between the relevance of organizational issues in relation to technical ones and regarding the clarity of guidance provided for these issues. Consequently, in this chapter we will review selected IFs and argue for a re-conceptualization of organizational interoperability and aspects of governance.
3.1
Purpose and Structure of IFs
At the European level, an IF is defined as “the set of policies, standards and guidelines describing the way in which organizations have agreed, or should agree, to do business with each other” (European Communities 2004). It provides the specifications for joining up the information systems of public administrations across the EU. EIF 2.0 gives a broader definition: An interoperability framework is an agreed approach to interoperability for organizations that wish to work together towards the joint delivery of public services. Within its scope of applicability, it specifies a set of common elements such as vocabulary, concepts, principles, policies, guidelines, recommendations, standards, specifications and practices (CEC 2010a, Annex 2, p. 2).
Similarly, NIFs provide “the policy and strategy by which e-government services are to be developed in order to ensure coherent flow of information across systems” (Lampathaki et al. 2011, p. 3).
3.1.1
Forerunners
Again, the phenomenon is much older than the term interoperability framework itself. We have mentioned that the OSI reference model was the first conception of interoperability, issued by ISO as a recommendation in 1984. Four years later, the National Institute of Standards and Technology (NIST) in the US approved the Government Open Systems Interconnection Profile (GOSIP) that demanded a shift from vendor-specific data communication protocols to open systems.allowing for the interoperation of systems of different manufacturers when required. In order to ensure interworking GOSIP was intended to serve as a procurement guideline for government agencies, which ordered their systems independently. The profile is the standard reference for all federal government agencies to use when acquiring and operating ADP (Automatic Data Processing) systems or services and communication systems or services intended to conform to ISO Open Systems Interconnection protocols which provide interoperability in a heterogeneous environment (NIST 1990, p. 1).
3.1 Purpose and Structure of IFs
37
Guijarro provides evidence that the US federal government and the Department of Defense (DoD) issued policy statements favoring OSI standards. The DoD even considered a shift from the TCP-IP protocol to OSI standards and, ultimately, allowed them as co-standards (Guijarro 2007, pp. 91f). Some years later, however, NIST in a revision of GOSIP, which was named Profiles for Open Systems Internetworking Technologies (POSIT), this preference for OSI standards was revised due to a lack of OSI-based products and services. This shift in standard setting policy acknowledged the rise of the Internet and broadened the range of products to be employed, still implementing open standards. Another GOSIP was developed in the UK and became the template for the European Procurement Handbook for Open Systems (Guijarro 2007, p. 92). Concern for a European effort arose for three reasons: 1. A large number of computer vendors faced interconnection problems with their systems; 2. Non-discrimination of manufacturers from Member States had become a political objective; 3. Interworking between governments of Member States and European institutions had emerged as an identified need. For a long time, only ICT experts were concerned with interoperability, but with the advent of the Internet matters changed, and interoperability became a priority topic at ministerial conferences and in council resolutions signaling that meanwhile Internet-based communication had become pervasive, and expectations had grown, that e-commerce and e-government would significantly further economic growth and social progress. Within the broader field of e-government, interoperability policy emerged as an explicit policy field of its own, and interoperability frameworks became a core element of this policy.
3.1.2
Interoperability Policy Context
In EIF 2.0, the role of frameworks within an interoperability policy is illustrated in Fig. 3.1. Frameworks are a first concretization of an interoperability strategy providing guidance for the design of e-government services but still needing further specification themselves through guidelines which support and direct implementation of services and tools. High expectations prevail with respect to what the EIF might ultimately lead to: The EIF provides recommendations that address specific interoperability requirements. Implementing the recommendations will create an environment conducive to public administrations establishing new European public services. This will help cultivate a European public service ecosystem with people familiar with interoperability, organizations ready to collaborate, and common frameworks, tools and services facilitating the establishment of European public services (CEC 2010a, Annex 2, p. 2).
38
3 Review of Prominent IFs and the Need for Re-conceptualization
Fig. 3.1 The role of frameworks within interoperability policy (CEC 2010a, Annex 2, p. 3)
3.1.3
Purpose and Relevance of EIF 2.0
The purpose of EIF 2.0 in the document is defined as follows: • To promote and support the delivery of European public services by fostering cross-border and cross-sectoral interoperability; • To guide public administrations in their work to provide European public services to business and citizens; • To complement and tie together the various National Interoperability Frameworks (NIFs) at European level” (Annex 2, p. 1). EIF 2.0 was designed to be a non-technical paper addressing “all those involved in defining, designing and implementing European public services.” Furthermore, the document “should also be considered, when establishing public services that in the future may be reused as part of the European public services.” Most relevant for national interoperability policy is the reference to NIFs, which is picked up in EIF 2.0 Recommendation 1: Recommendation 1: Public administrations should align their interoperability frameworks with the European Interoperability Framework to take into account the European dimension of public service delivery (Annex 2, p. 4).
Indeed, more than a recommendation appears in the i2010 eGovernment Action Plan 2006–2010 (COM 2006/173) which Sought to ensure that e-government at [the] national level does not lead to new barriers within the single market because of fragmentation and lack of interoperability. More recently, in the Malm€ o Ministerial Declaration of 18 November 2009, ministers responsible
3.1 Purpose and Structure of IFs
39
for e-government policy agreed to improve the trustworthiness, security and interoperability of e-government services and systems within the single market. They agreed to align their national interoperability frameworks with applicable European frameworks and invited the Commission to identify gaps in cross-border interoperability and mutual recognition, as well as intensifying activities on key enablers. Moreover, Member States recognized that better public services need to be delivered with fewer resources, and that the potential of e-government can be boosted by promoting a culture of collaboration and by improving the conditions for interoperability in European public administrations. (CEC 2010a, p. 5)
3.1.4
Building Blocks and Key Areas
IFs provide a cognitive map of the relevant aspects and types of measures necessary to achieve interoperation. They primarily achieve this by proposing a number of layers, which serve as containers to be filled with certain kinds of standards. • EIF 1.0 introduced three key areas of technical, semantic, and organizational interoperability and made a number of recommendations for national IFs. • In a similar architectural model, the European Public Administration Network (EPAN) added the layer of structured customer contact and support and, besides the four layers, introduced the idea that governance is a crosscutting issue (EPAN 2004). • In a white paper with the title “Standards for Business”, the European Standardization Institute ETSI introduced the layer of syntactic interoperability between the technical and the semantic interoperability (ETSI 2006). • On the basis of comparative analysis of 12 different IFs, Peristeras and Tarabanis (2006) suggested a concept of their own which they called “The Connection, Communication, Consolidation, Collaboration Interoperability Framework (C4IF)”. The four terms characterize the functions or purposes that the standard should fulfill within the different layers of the frameworks mentioned above.
3.1.5
The Political Controversy About Openness
Today, IFs are not explicitly issued as procurement handbooks, but they still have impact on public procurement. And because governments are important customers in the ICT business, the ICT industry not only observes but also lobbies for certain recommendations. The most critical and controversial recommendation concerns open standards and open source software. In EIF 1.0, Recommendation 2 advises the “Use of open standards” and to “Assess the benefits of open source software” for any e-government services to be set up at a pan-European level (European Communities 2004, p. 9). Open standards are defined as follows:
40
3 Review of Prominent IFs and the Need for Re-conceptualization “To attain interoperability in the context of pan-European e-government services, guidance needs to focus on open standards. The following are the minimal characteristics that a specification and its attendant documents must have in order to be considered an open standard: • The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.). • The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee. • The intellectual property – i.e., patents possibly present – of (parts of) the standard is made irrevocably available on a royalty-free basis. • There are no constraints on the re-use of the standard” (European Communities 2004, p. 9).
The term “standard” here is used in its broadest sense: “It includes all specifications, having gone through a standardization process, which is compliant with the principles outlined above. The Directive 98/34/EC, which lays down a procedure for the provision of information in the field of technical standards and regulations, defines a standard as a technical specification approved by a recognized international, European, or national standardization body. All standard-related definitions will be analyzed in 2005 in the framework of the review of the Directive 98/34/EC” (European Communities 2004, p. 9). Regarding open source software, EIF 1.0 explains: Open Source Software (OSS) tends to use and help define open standards and publicly available specifications. OSS products are, by their nature, publicly available specifications, and the availability of their source code promotes open, democratic debate around the specifications, making them both more robust and interoperable. As such, OSS corresponds to the objectives of this Framework and should be assessed and considered favorably alongside proprietary alternatives.
Vendors such as Microsoft, Adobe, Cisco, Oracle, and Sun did not welcome this recommendation since they had already established their products as de facto standards. When the draft for EIF 2.0 was published for consultation (European Communities 2008), it contained a stronger recommendation for open standards and a more detailed explanation (see left part of box). Lobbyists of the ICT industry tried to remove or revise this recommendation. According to some blogs, they were successful and extruded a more open formulation. But this in turn provoked criticism from government representatives and the open source community, which ultimately led to another revision. Recommendation 6 in EIF 2.0 resulted from these negotiations (right part of box). Notably, the terms “open standards” and “open source software” are neither used in the recommendation nor in the underlying principle. Additionally, the glossary does not explain openness or open standards; rather, it quotes two references for “Open Source or Open Source Software (OSS)” (p. 32). While this lack of clarity in these paragraphs seems like a step back from favoring open standards, in fact, the clear-cut statement had only been shifted to
3.1 Purpose and Structure of IFs
41
Box 3.1 Comparison EIF 2.0 Draft and Final Text Draft 2008 Recommendation 5: Public administrations should favor openness when working together to establish European Public Service while taking into account their priorities and constraints.
Final text 2010 Recommendation 6: Public administrations should aim for openness when working together to establish “European public services while taking into account their priorities and constraints”.
Underlying Principle: Within the context of the EIF, openness is the willingness of persons, organizations or other members of a community of interest to share knowledge and to stimulate debate within that community of interest, having as ultimate goal the advancement of knowledge and the use thereof to solve relevant problems. In that sense, openness leads to considerable gains in efficiency Interoperability involves the sharing of information and knowledge between organizations, hence implies a certain degree of openness. There are varying degrees of openness Specifications, software and software development methods that promote collaboration and the results of which can freely be accessed reused and shared are considered open and lie at one end of the spectrum, while non-documented, proprietary specifications, proprietary software and the reluctance or resistance to reuse solutions, i.e., the “not invented here” syndrome, lie at the other end The spectrum of approaches that lies between these two extremes can be called the openness continuum European public administrations need to decide where they wish to position themselves on this continuum with respect to the issues discusses in the EIF. The exact position may vary, on a case-by-case basis, depending on their needs, priorities, legacy, budget, market situation and a number of other factors. While there is a correlation between openness and interoperability, it is also true that interoperability can be obtained without openness, for example via homogeneity of the ICT systems, which implies that all partners use, or agree to use, the same solution to implement a European Public Service
Underlying Principle 9: Openness: “In the context of the EIF, openness is the willingness of persons, organizations or other members of a community of interest to share knowledge and stimulate debate within that community, the ultimate goal being to advance knowledge and the use of this knowledge to solve problems”
While expecting data protection and privacy, interoperability involves sharing information among interacting organizations, and hence implies openness Applying the principle of openness when jointly developing custom-made software systems, European public administrations generate results that can be connected, reused, and shared, which also improves efficiency
Therefore “European public administrations should aim for openness, taking into account needs, priorities, legacy, budget, market situation and a number of other factors”
42
3 Review of Prominent IFs and the Need for Re-conceptualization
another section addressing “Assessing and selecting formalized specifications” with two recommendations (see text box below). While bloggers still criticize this revision, we argue that from a scientific and methodological point of view, advantages and disadvantages exist both for open standards and open source software and for branded proprietary systems. Moreover, no valid methodology for cost-benefit analyses exists such as a totalcost-of-ownership comparison, e.g., of the Microsoft Office suite and equivalent open source products for different government authorities. Assessing and Selecting Formalized Specifications Recommendation 21: Public administrations should use a structured, transparent and objective approach to assessing and selecting formalized specifications. When public administrations select the formalized specifications or technologies to ensure interoperability, they should assess relevant formalized specifications. This assessment should be tailored to the specific interoperability needs of the public administrations in question, but based on objective criteria, primarily related to functional interoperability needs. When several formalized specifications meet functional interoperability needs, additional criteria on quality of implementation, market support, potential for reusability and openness can be used. Specifications, openness and reuse Recommendation 22: When establishing European public services, public administrations should prefer open specifications, taking due account of the coverage of functional needs, maturity and market support. The level of openness of a formalized specification is an important element in determining the possibility of sharing and reusing software components implementing that specification. This also applies when such components are used for the establishment of new European public services. If the openness principle is applied in full: • All stakeholders have the same possibility of contributing to the development of the specification and public review is part of the decision-making process; • The specification is available for everybody to study; • Intellectual property rights related to the specification are licensed on FRAND terms or on a royalty-free basis in a way that allows implementation in both proprietary and open source software. Due to their positive effect on interoperability, the use of such open specifications, characterized by the features mentioned above as well as the sharing and reuse of software implementing such open specifications, has been promoted in many policy statements and is encouraged for European public service delivery. The positive effect of open specifications is also demonstrated by the Internet ecosystem. However, public administrations may decide to use less open specifications, if open specifications do not exist or do not meet functional interoperability needs. In all cases, specifications should be mature and sufficiently supported by the market, except if used in the context of creating innovative solutions.
However, neither EIF 2.0 nor NIFs of Member States propose detailed methods and criteria for evaluation and selection of the standards listed. For this purpose Mykk€anen and Tuomainen (2008) have proposed a methodology including criteria such as: • Scope of a standard. • Information and semantics of the standard.
3.2 Building Blocks of EIF 2.0
• • • • • •
43
Functionality. Application infrastructure. Technical aspects, i.e., openness. Flexibility, accuracy, extensibility. Maturity, usage, official status. Systems lifecycle.
For each aspect, several items are listed compiled in nine separate forms and tables. These sheets are indicative of the complexity of applying an interoperability framework because a comparative evaluation has to be conducted for several standards on each layer. The comparison of “openness” in this context appears to be a real challenge.
3.2
Building Blocks of EIF 2.0
EIF 2.0 includes four building blocks: • Twelve principles underlying European public services, e.g., subsidiarity, usercentricity, openness, reusability, and adaptability; • A conceptual model for public services, defining basic components, for which interoperability is required; • The multi-layer model; • Interoperability agreements. The conceptual model is a kind of reference model distinguishing different components of an electronic public service, which can be designed separately and reused for different services (see Fig. 3.2). Starting from the bottom of Fig. 3.2, the three most basic components are highlighted, on which any public service should be able to build: • Core registries provide reliable sources of basic information on persons, companies, vehicles, buildings etc. They are maintained by designated public authorities but should be made available to other public agencies and business as well. For information sharing security, appropriate access and control mechanisms should be implemented to ensure security and privacy, in accordance with the relevant legislation. • External services include payment services provided by financial institutions. • Interoperability facilitators act as information brokers or provide services such as translation between formats or protocols. Access to these basic services should go through a harmonized and controlled layer, which provides for the secure exchange of certified messages, records, forms, and other kinds of information. Specific security provisions include electronic signatures, encryption, and time stamping. These particular services should both
44
3 Review of Prominent IFs and the Need for Re-conceptualization
Fig. 3.2 Basic conceptual model in EIF 2.0 (CEC 2010a, Annex2, p. 14)
be common for different public services and harmonized. At the same time, they must account for different security requirements. Separated from secure data exchange management is secure communication management, i.e., service registration, logging, and service management. Specific examples include the processes of authentication and authorization of users. Primary public services such as filing tax returns or applying for licenses use these services and functions. Such public services are called aggregate public services because they are offered by several administrative agencies at different levels of government and therefore require some orchestration, such as interoperability of messages, data, and workflows. Starting from the top of the model, users expect access to public services not only through government portals but also through intermediaries. They expect a single sign-on or at least similar authentication processes as well as a complete online transaction. This requires horizontal integration to aggregate and orchestrate previously separated online processes in the front office. In order to be cost effective, these primary public services to citizens and businesses must share basic components or secondary supportive services. This sharing then creates a need for interoperability between elements on each lower level. Competing public or private organizations need to offer at least common interfaces. For electronic signatures, for example, standards have been defined but are not yet fully implemented.
3.2 Building Blocks of EIF 2.0
45
Fig. 3.3 Five layers of interoperability in EIF 2.0 (CEC 2010a, Annex 2, p. 21)
The original three layers of technical, semantic and organizational interoperability, now called “levels,” have been topped by a layer of legal interoperability and a layer of political context (see Fig. 3.3). We will come back to this innovation in the next section. The recommendation of interoperability agreements is another addition to EIF 2.0. They are introduced as an approach “to facilitate cooperation among public administrations to provide a given European public service”: . . . providing European public services requires cooperation among different public administrations at the different interoperability levels described in the previous chapter. For each level the organizations involved should formalize cooperation arrangements in cooperation agreements.
Agreements should be drafted with sufficient detail to achieve their aim to provide a “European public service – while leaving each organization a maximum internal autonomy” (Annex 2, p. 15). The EIF emphasizes that interoperability agreements should refer to existing formalized specifications, and, when these do not exist, then governments should cooperate with other communities in the standardization process. Where several specifications are available, the choice should be based on “transparency, fairness and non-discrimination”. Therefore, interoperability agreements should include a common assessment methodology and selection process.
46
3 Review of Prominent IFs and the Need for Re-conceptualization
3.3
Enterprise Architectures and Reference Models
The development of and the discussion about IFs in the e-government context has been heavily influenced not only by the OSI approach but also by so called enterprise architectures (EAs) and other reference models. In his survey of interoperability frameworks, Guijarro includes NIFs of Denmark, France, Germany, the UK, and the EU as well as the E-Government Enterprise Architecture Guidance (EAG) issued by the Federal Chief Information Officer Council (CIOC) in the US. The author maintains that enterprise architectures and IFs are functionally equivalent tools for providing guidance to public agencies when developing IT plans and projects (Guijarro 2007, p. 93). As several contributions to the volume edited by Charabilidis (2011) show, the concept of “enterprise” and enterprise architectures gain momentum in the e-government literature, and seemingly the underlying assumption is that the public sector could learn from these concepts and their application in the private sector (Pardo et al. 2011, pp. 4f.). An enterprise in this context may be a single private-sector for-profit organization, a larger private-sector corporation with several business units, or a conglomerate of multiple organizations, but also a public organization, or even an entire government. The elements described in an enterprise architecture include business objectives, business functions and business processes, which are looked at from different perspectives emphasizing either data, applications, networks and other infrastructure components. An early approach of this kind is a reference model proposed by IBM researcher Zachman (1987) dealing with the what, how, where, who, when and why for data, function, network, people, time and motivation for electronic processes. Based on his analysis of several IFs Guijarro, argues that the Federal Enterprise Architecture of the US Chief Information Officer Council (CIOC) is the most mature initiative. The Office of Management and Budget of the Executive Office of the President of the United States (OMB) adopted it in 2001. This move requires the compliance of all federal departments to the four main documents, the business architecture, the data architecture, the application, and the technology architecture. According to Guijarro, the OMB and the CIOC “have required the adoption of the models as a condition for budget approval” (Guijarro 2006, p. 99). In his introduction to a case study on interoperability in the Danish medical sector, Madsen refers to the assumption that EAs are a popular approach in many public agencies for developing interoperable e-government services (Hjort-Madsen 2006, p. 1): The goal is the full articulation of all levels of an enterprise integrating the strategic and business processes with the information technology and data systems that enable them. . . . The strength of an EA is that it embraces both the front- and back-office focus along with a governance model that guides the use of IS from a business perspective. Thus many public practitioners believe that EA is the solution to the integration and interoperability challenges that the public sector is facing today (p. 2).
3.3 Enterprise Architectures and Reference Models
47
Without any doubt there is a similarity of IFs and EAs But the focus of EAs may not be as explicit on interoperability issues as with IFs, although interoperability is at least implicitly a necessary condition for all components of an EA. While IFs are developed and issued by CIOs in government, EAs originate from the academic or ICT industry. In the e-government context, EAs are sometimes complementary to IFs. For example, in the UK, eGIF is part of an e-Services Development Framework (e-SDF). This framework also includes a Common Information Model, a Government Data Catalogue, a Message Reference Model, and the High-Level Architecture (Hjort-Madsen 2006, p. 97). Similarly, the Danish Ministry of Science, Technology, and Innovation announced a common EA framework that includes coordination mechanisms and methodologies for common choices and principles with regard to standards and infrastructures, repositories etc. From his review, Guijarro draws a two-phase interoperability roadmap: A first phase would consist of enabling interoperability, namely providing the basic technical standards and policies to enable the seamless flow of information between different administrations in the delivery of e-services. In this phase interoperability frameworks can be regarded as an appropriate tool. A second phase facilitates the alignment of the administrative procedures with the technical systems; the result of this alignment contributes to interoperability at the organizational level between different administrations. In this phase, the enterprise architecture is a promising tool that the US e-government initiatives have thoroughly tested and deployed (Hjort-Madsen 2006, p. 100).
But it may well be the other way around: the Zachman Architecture, at least, is a reference model of what has to be considered when planning and designing different systems within a larger context. In any case, so far there is little evidence of agencies adhering to this rule or agencies applying or bypassing this requirement. Madsen points to the fact that government is organized differently than enterprises, more like networks than hierarchies, and that CIOs do not have the same authority in government as their colleagues in industry. Madsen and Pries-Heje analyzed the implementation of the Danish EA by conducting focus group interviews with CIOs from different government sectors. The EA has been elaborated by the consulting company Gartner for the Ministry of Science, Technology, and Innovation (MSTI), which is responsible for the IT systems in Danish government and expected a new approach and tool for improving interoperability between the separated systems in Danish government. But top-level responsibility for e-government resides with the Ministry of Finance (MF). MSTI tried to gain more political influence via EA but officials in charge of IT in several ministries had set other priorities or were committed to other coordination efforts. This case reveals two basic weaknesses of enterprise architectures: First, they assume a pre-existing, relatively coherent governance structure. Second, when previously separated databases or processes of independent organizations have to be technically and organizationally integrated, EAs would be of no much help either. We will return to this implementation study in the final chapter.
48
3.3.1
3 Review of Prominent IFs and the Need for Re-conceptualization
Broader Reference Models
In the academic e-government literature we also find broader reference models pointing to the non-technical elements of an interoperability strategy or policy. For example Hagen, based on case studies of e-government projects in Germany and the US, has developed a reference model for constructing online-transaction systems in public administration. This model includes 12 basic functions, 12 complementary and supporting measures, and 8 context conditions (Hagen 2001). Figure 3.4 provides a translation of the 32 aspects. It is outside the scope of this report to go deeper into each of these factors, but a short look at the model reveals how complex the development of a single online service is, and that interoperability and adherence to certain standards is just one requirement of many. From the point of view of those responsible for providing a public service, interoperability might appear as a low-priority objective imposed by external authorities.
Fig. 3.4 Reference model for e-government (Hagen 2001, translated from German)
Another relevant frame of reference is the Government Interoperability Improvement Framework developed by Pardo and Burke at the Center for Technology in Government in Albany, N.Y. (Pardo and Burke 2008a, b). These authors propose three maturity levels of interoperability in e-government:
3.4 Comparisons of National Interoperability Frameworks
49
Government interoperability framework maturity levels (Pardo and Burke 2009, p. 2) Level 1 There may be evidence of interoperability within individual government organizations, but there is little to no evidence of any interoperability across agency or organizational boundaries. At this level, government agencies work independently and do not share information with other organizations; government or private sector. In addition, there is little evidence of the decision making, strategic planning, and resource and project management structures and processes needed to develop and manage ongoing or future initiatives requiring improved government interoperability. Level 2 There is evidence of interoperability in specific policy or program areas. However, there is little evidence of interoperability across multiple networks (e.g. criminal justice networks cannot share information with public health networks). In addition, while interoperability initiatives in these areas may be planned and managed in a consistent way, the process for selecting, controlling, and evaluating initiatives is not consistent or standardized across networks or at a government wide level. Level 3 There is evidence of interoperability across multiple networks. For example, public health and criminal justice networks can effectively share information across their two networks in support of the larger policy goal of public safety. In addition, consistent and standardized processes and structures are in place to develop and manage government interoperability initiatives regardless of policy domains. As a result, existing networks can scale and apply resource sharing and process integration across multiple policy and program areas as needed, essentially creating new networks.
In order to improve interoperability and to proceed to the next higher maturity level capabilities have to be improved in several fields (ibid, for more details see Pardo and Burke 2008a). Again we cannot go deeper into these issues but only stress their importance for practical success of interoperability initiatives and the implementation of IFs. Managing capabilities for interoperability initiatives • Governance • Strategic planning • Business case development • Project management • Resource management • Stakeholder identification &engagement • Leaders & champions • Business & technology architectures • Performance evaluation
3.4
Information sharing capabilities • Collaboration readiness • Organizational compatibility • Information policies • Change acceptance • Technology knowledge • Data assets & requirements • Secure environment • Technology compatibility
Comparisons of National Interoperability Frameworks
The EIF admits that it is more general than national IFs. NIFs are often more specific because they specifically address the national government or the national and next lower level of government of one country.
50
3 Review of Prominent IFs and the Need for Re-conceptualization
No systematic comparisons of NIFs existed when the research reported here began. The MODINIS study on Interoperability at the Local and Regional Level provided a synopsis of the status of interoperability in 25+ Member States, summarizing the e-government interoperability strategy, the main actors, the implementation programs, and example projects at the local level for each country. This study did not provide an explicit comparative analysis (Tambouris et al. 2007). In 2007, Guijarro published a short comparative analysis of the NIFs of the UK, France, Germany, Denmark, the EU, and the US (Guijarro 2007). In 2009, Gartner Group submitted a final report for the first phase of the National Interoperability Framework Observatory (NIFO), presenting an analytical model for a systematic comparison (Gartner 2009, for the NIFO project see also the profile on the e-practice portal at http://www.epractice.eu/cases/nifo). In March 2009, the NIFO compiled a synopsis of 33 European countries, including all EU Member States, Iceland, Switzerland, Norway, Liechtenstein, and Turkey. At the time of the survey in 2008, only 10 out of 30 countries had issued a NIF, 3 had an alternative scheme, in 13 countries an EIF was under development, 3 had no plans and for another 4 no information was available (see Table 3.1). In 2010, four more countries published a NIF, allowing for a comparative analysis of 14. The analysis covered more than 100 items. National experts provided data. These same experts were asked to assess the degree to which the issues addressed were present on a five-point scale ranging from 1 to 5. 1. There is no tangible evidence that his criterion has been covered. 2. There is material available for this aspect but it is not usable for evaluation of the NIF. 3. There is material available for this aspect; it is relevant for evaluation of the NIF but not sufficient. 4. The NIF has adopted an approach for this criterion, without judging whether this approach provides full or partial coverage for the criterion. 5. The NIF has adopted an approach for this criterion. The approach provides full or partial (but sufficient) coverage for the criterion.
3.4.1
Political Context
The first set of aspects has been grouped under the heading of “Context and Principles” and deals with the coverage of the NIFs and their governance. Table 3.2 Table 3.1 State of NIFs in Europe (IDABC 2009a) NIF established
10
Alternative Under development Not planned No information
3 13 3 4
Bulgaria, Denmark, Estonia, Germany, Greece, Hungary, Italy, Poland, United Kingdom, Turkey Finland, Latvia, Slovakia Austria, Belgium, Cyprus, France, Iceland, Lithuania, Malta, Netherlands, Norway, Poland, Romania, Slovenia, Spain Czech Republic, Ireland, Sweden Liechtenstein, Luxembourg, Portugal, Switzerland
Table 3.2 Interoperability (IOP) context and principles (IDABC 2009b) in national interoperability frameworks Selected items IOP context and principles DE DK MT BE BG EE GR What type of interoperability relationship is in scope of the NIF? G2G: 5 – 4 – 3 – – Government-to-government. G2C: government-to-citizen. G2B: government-to-business. G2Orgs: government-to-organizations (nonprofit, semi-governmental, foundations). G2OG: government-toother-government (cross-state or cross-border) Is a centrally governed implementation process in place, that is: the 2 – – 2 4 4 3 actual application of the NIF standards//recommendations in public services? Are metrics defined, mapped to the goals to measure achievement of the 2 1 3 2 1 3 3 goals? Are regular measurements taking place? If available, are any metrics specific to the NIF? Does an e-government roadmap exist, coupled with goals, vision and 1 3 3 2 4 3 3 strategy? If yes, is the NIF explicitly linked to this roadmap? Is the usage//application of the NIF measured? Does regular surveying – – – – 3 – 3 and reporting exist? IT architecture aims to achieve reuse of IT assets in the broadest sense 0 0 0 1 3 3 0 (messages, components, services). Is actual re-use measured and reported? Total score 132 97 110 104 142 147 134 3 4 4 1
3 3 1 0
0
–
4
3
1
1
1
4
3
3
1
3
2
3
RO TR 2 2
4
1
4
4
5
UK 4
132 153 121 134 125 150 160
0
–
4
2
2
5
2
4
NL PL – –
HU IT – 2
3.4 Comparisons of National Interoperability Frameworks 51
52
3 Review of Prominent IFs and the Need for Re-conceptualization
depicts some of the quantitative scores. According to these figures only the German NIF SAGA provided full, or at least extensive, coverage of all five areas of e-government (first line in Table 3.2). In contrast, countries such as Italy, Romania, and Turkey received a score of 2 because the official documents were not clear about their area of application. The second item in Table 3.2 concerns the degree to which a centrally governed implementation process is in place. The UK, Italy, Estonia, Bulgaria, and Poland received high scores whereas Germany, Belgium, Hungary, and the Netherlands ranked lowest on this criterion. Defined metrics for assessing the achievements in interoperability were most fully developed in Romania and the UK and were least developed in Denmark and Bulgaria. E-government roadmaps were most elaborated in Bulgaria, Italy, the Netherland, Poland, and the UK. The usage of the NIF was measured most comprehensively in Italy whereas Hungary, Romania, Turkey and the UK showed the lowest scores. For 6 of 14 countries, no data were reported. The observatory finally has calculated a summative index of all items, which is reported in the bottom line of the Table 3.2. These numbers should not be taken too seriously, and they certainly do not allow for any benchmarking because their validity might be questionable from a methodological standpoint. Experts looking at only one NIF each assigned these scores. As a result, the scores probably rest on divergent interpretations of the scaling, and thus use different yardsticks. But even with this rater-related variance, we can still conclude that the 14 EIFs vary widely in content and context. For each item and each country, besides the score on the five-point scale, comments were made which gave some background information. Box 3.2 lists the comments on how governance of NIFs is organized (see Box 3.2).
3.4.2
Legal Aspects
Three items deal with liability and compliance. Most NIFs contain a combination of recommendations (guidelines) and mandatory aspects. The mandatory aspects seem strongest in Estonia, Greece, Turkey, and the UK. Notably, only Bulgaria, Italy, Poland, and Romania receive a high score on enforcement aspects (see Table 3.3). Experts were also asked: “What is the overall compliance regime?” • Guideline: recommended and (strongly) advised to follow. • Mandatory: mandatory to follow, but not formally enforced and/or no penalty regime. • Law-enforced: fully mandatory and enforced, through law or equivalent strong legal basis. Participants could choose “Yes” (5 Points) or “No” (0 Points). Only 5 out of 14 countries received five points. The narrative assessments for these cases are the following:
3.4 Comparisons of National Interoperability Frameworks
53
Box 3.2 Interoperability Governance at Political Level (NIFO 2010) DE SAGA governance, and its relationship with DOL, reflects the German federal system. In practice, SAGA is only used at the Federal Government level, with the Ministry of the Interior as key user and owner. Other Ministries apply SAGA at their discretion. As of now, there is no formal governance processes aligning the Ministries or other levels of government, but this is under discussion DK Danish government is 3-tier: municipalities, regions and the national government. The OIO Committee is part of and funded by the national government and has representatives of the other tiers. Every year, at the annual budget meeting, all government tiers have to agree on the standards that will become mandatory. For the rest of the year, the tiers work mostly independently This process works and is repeatable, but is not formalized or published in any form MT Governance surrounding the NIF has not been formalized BE They are three levels of administration in Bulgaria: central administration (including: primary bodies (the Ministries) and secondary ones (the Agencies)); regional administration (28 regions) and municipalities (262). Some of the central bodies have local branches (mostly in the municipal centers). It is necessary to underline that the rules and requirements of NIF are universal and apply equally to all administrations. For example, the Unified environment for e-Document exchange does not distinguish between participants, whether the Ministry or Municipality BG The governance surrounding the Framework and other e-government initiatives is centralized with the Department of State Information Systems (RISO), part of the Ministry of Economic Affairs and Communications. The open character of the public consultation rounds and the transparent, principle-driven approach form a clear reflection of overall, nation-wide egovernment and Information Society plans, initiated by the national government IT The concept of SPC is introduced in the CAD and ratified by Italian Parliament. The overarching Enterprise Architecture model and compliance rules are updated by decree of Minister for Public Administration and Innovation. The core of SPC, the documents, guidelines and standards, are maintained by the SPC board working group and CNIPA. The board contains representatives from all layers of government NL Governance of the various initiatives is organized along the lines of Dutch government. At the national level, the Ministry of the Interior sets policies for government bodies and owns and maintains NORA. The other layers of government (provinces, municipalities and water control boards) each have their own refined reference architecture based on NORA The Ministry of Economic Affairs promotes open standards for better interoperability, less dependence on software suppliers and innovation (open source software) PL The Interoperability Frameworks assigns responsibility to the Department of Information Technology of the Ministry of Interior and Administration to evaluate recommendations and update the Framework at least once a year. Recommendations are gathered using a formal public consultation process. An advisory body is to be installed RO Law 329/2009 on the modernization and reorganization of (parts of) Romanian government, which was at time of review in parliament, clearly assigns responsibility of the interoperability framework to CNMSI. Detailed governance and development/maintenance processes for the framework and its standards are yet to be detailed further TR At the political level, governance for the Interoperability Guide is centralized, in line with the centralized nature of the Information Society program and the centralized organization of the State Planning Organization. At the highest level, governance and ownership is delegated to the SPO by means of the Prime Minister’s Circular. In that circular, a link to the website of SPO is given that always contains the latest set of applicable standards UK The governance surrounding the ICT Strategy and the underlying assets is centralized with the Government CIO Council, which is supported by the Cabinet Office. The CIO Council involves the wider public sector and other boards and collaborative bodies. Reporting to the CIO Council is the ICT Strategy Implementation Working Group and the CTO Council, amongst others The UK government structure is reflected through the decentralized nature of the actual implementation of the strategy, with central steering in place
54
3 Review of Prominent IFs and the Need for Re-conceptualization
Table 3.3 Legal aspects of NIFs (NIFO 2010) Legal aspects Does the NIF cover guideline aspects for interoperability? Does the NIF cover mandatory aspects for interoperability? Does the NIF cover enforcement aspects for interoperability?
DE DK MT BE BG EE GR HU IT NL PL RO TR UK 5 3 4 3 4 4 4 3 4 5 3 4 5
4
3
3
2
4
5
5
4
4
4
1
-
5
5
3
3
2
1
5
3
3
4
5
1
5
5
3
1
• Bulgaria: The Bulgarian NIF was fully law-enforced. The rule-set was centrally maintained and updated, and new connections to the central communications infrastructure and/or new document types needed to be certified beforehand. This certification process was governed centrally, but executed by third parties through an accreditation scheme. • The Greek e-GIF was regulated by law, which applied to both the framework itself as well as the maintenance processes that surrounded it (including appointing the responsible department in the Ministry of the Interior). It was, however, not mandated or enforced by law, and the maintenance process was not described by law or statute. • Italy: The SPC was fully mandated by the Law on Digital Administration (Codice dell’Amministrazione Digitale – CAD). Enforcement was done through a certification process. • Poland: The interoperability framework as well as the existing interoperability guidelines were all law-enforced in Poland: the core standards around electronic communications (protocols) and mandatory fields in electronic messages were explicitly laid down in law. • Romania: The proposition was to impose standards using a legal basis for the NIF. A law to this effect was under consideration in the parliament when this report was prepared.
3.4.3
Layers of Interoperability
NIFs were also surveyed about the layers of interoperability covered. Technical aspects in 12 out of 14 NIFs received the highest score (Table 3.4). Semantic interoperability scores varied, with Denmark, Bulgaria, Italy, and the UK receiving high scores, Belgium receiving the lowest score, and Germany and the Netherlands also receiving low scores. Still greater variance was reported for aspects of organizational interoperability, with Denmark at the bottom end. Again, taking into account the methodological weakness of these scores, within each framework the three topical layers likely received different degrees of attention. At the same time, some NIFs appeared to pay more attention to semantic issues compared to organizational interoperability.
3.5 Relevance and Fuzziness of Organizational Interoperability
55
Table 3.4 Layers of interoperability (IOP) in NIFs (NIFO 2010) Layers of IOP Is the organizational level of interoperability in scope of the NIF? If yes, summarize Is the semantic level of interoperability in scope of the NIF? If yes, summarize Is the technical level of interoperability in scope of the NIF? If yes, summarize
DE DK MT B BG EE GR HU IT NL PL RO TR UK 3 1 5 1 2 4 3 1 5 4 4 3 3 3
2
5
3
1 5
4
4
4
5
2
4
3
3
5
5
3
3
5 5
5
5
5
5
5
5
5
5
5
Looking closer at how organizational interoperability was dealt with in the NIFs, variance also occurs between general guidelines, repositories describing services and overarching processes, and organizational elements supporting content aggregation or process alignment. At the time of this writing, no final report had been published providing any conclusions. The summary of the study in the Good-Practice Portal (http://www. epractice.eu/cases/nifo), however, concluded: “The key conclusions after comparative analysis, for each of the three perspectives in the Analytical Model, are: Perspective Context and Principles • Significant progress on interoperability can only be achieved by taking all contextual factors into account; • Communication and creating awareness is a key factor in order to create momentum; • Measurement of interoperability effectiveness is needed in order to demonstrate the added value Perspective Interoperability • Mandating interoperability with a legislative framework is difficult but effective; • Organizational interoperability is covered only rarely. Countries tend to emphasize semantic and technical levels of interoperability, which actually are only enablers for organizational interoperability. Perspective Services Support • “Well defined, transparent lifecycle management of the NIF and the creation of a community around the NIF are critical success factors for full NIF maturity and adoption.”
3.5
Relevance and Fuzziness of Organizational Interoperability
Comparing the elements assigned to the four layers of interoperability we find a striking mismatch between relevance and clarity (see Table 3.5). As we have stressed in the introduction, the clarity of recommendations for achieving organizational interoperability stands in inverse proportion to its relevance and importance. While international standards and protocols for the layers of technical and
56
3 Review of Prominent IFs and the Need for Re-conceptualization
Table 3.5 Knowledge states of five layers of interoperability Layer of interoperability
Aim
Objects
Solutions
State of knowledge
Technical interoperability Syntactical interoperability
Technically secure data transfer Processing received data
Signals
Fully developed
Semantic interoperability
Processing and interpretation of received data
Information
Organizational interoperability
Automatic linkage of processes among different systems
Processes (workflow)
Legal interoperability
Legal validity of data exchange
Legal provisions
Protocols of data transfer Standardized data exchange formats (e.g. EDIFACT, XMLsyntax) e.g., XML schemes, common directories, data keys, ontologies Architectural models, standardized process elements (SOA) Legislative action, i.e., adaption and harmonization of existing laws and/or issuing new legislation
Data
Fully developed
Theoretically developed, but practical implementation problems Still lack of conceptual clarity, vague concepts with large scope of interpretation Professional legal knowledge available, but not easily matched with technical knowledge
syntactic interoperability exist, and recognized concepts and methods for the semantic interoperability are available, very heterogeneous elements and aspects are assigned to the layer of organizational interoperability. These elements are either described only vaguely, or they are formulated as requirements instead of options for action. The newly introduced layer of legal interoperability refers to the adaption and harmonization of legal provisions, which is quite different from developing or selecting ICT standards for data transmission. In EIF 2.0, legal interoperability is only briefly introduced: Each public administration contributing to the provision of a European public service works within its own national legal framework. Sometimes incompatibilities between legislation in different Member States make working together more complex or even impossible, even where such legislation is the result of transposing European directives into national law. Legal initiatives may be needed to remedy such situations (Annex 2, p. 22).
In other words, legal action is recommended in order to harmonize legislation of Member States to allow for data exchange in European public services. The same problem arises within Member States with a federal structure and state legislation, such as Germany, and Member States with regional legislation, such as Belgium and Spain. In addition, EIF 2.0 points to the need for adapting national legislation when the implementation of interoperable public services generates new issues that need to be dealt with, such as keeping digital information secure.
3.5 Relevance and Fuzziness of Organizational Interoperability
57
When information is exchanged between Member States to provide European public services, the legal validity of such information must be maintained across borders and data protection legislation in both originating and receiving countries must be respected (Annex 2, p. 22).
Perhaps asking every national e-government project to check the respective legislation in 27+ other Member States is asking too much. In any case, accordance with European directives, such as those regarding telecommunication, electronic signatures, public procurement, and domain-specific requirements, should be considered. While good reasons exist for bringing the legal aspects to the attention of political stakeholders and system developers, introducing another layer or level is not the appropriate way to do so. The main objection is that legal issues include legislation, contracts, and agreements and that refer to organizational, semantic, syntactic and technical issues. In that way, legal issues are cut across dimensions and layers. The basic assumption of the OSI Reference Model is that each layer provides a service to the next higher level and relies on services provided by the layers below. Because the layers of technical, syntactic, semantic, and organizational interoperability do not provide services to legal provisions, the placement of legal issues within the IFs must be changed. Organizational interoperability, which is even more heterogeneous and fuzzy than legal issues, should also be re-conceptualized. The following box summarizes the definition of organizational interoperability in selected frameworks. To this layer all those elements and measures were assigned, which turn out to be necessary after interoperability has been achieved on the layers below. Definition of Organizational Interoperability in Different Framework Concepts IDABC EIF 1.0 Organizational interoperability is concerned with “defining business processes and bringing about the collaboration of administrations that wish to exchange information and may have different internal structures as well as aspects related to requirements of the user community” (European Communities 2004, p. 16). EPAN Organizational interoperability “is concerned with the coordination and alignment of business processes and information architectures that span both intra- and interorganizational boundaries . . . Coordination of business processes across organizational boundaries is essential, if a single, aggregated view of a service from the customers’ perspective is to be achieved. It is suggested that administrations could develop an exemplar scheme that would define standard approaches to each of the main requirements of any public service and use this exemplar to benchmark all other services; that common functionality could be provided on a shared basis through a broker service to reduce development, deployment and operational costs to the public administration and to each service fulfillment agency, and to ensure consistency of experience for users of services across all agencies in the public sector through the use of agreed standards across all services; that expenditure reviews could be undertaken to ensure that financial priority is given to those schemes that comply with the structured customer support services set out above and with interoperability standards; and that each administration could develop a central programmer of organization development assistance and funding to bring this change about” (EPAN 2004, pp. 5f). (continued)
58
3 Review of Prominent IFs and the Need for Re-conceptualization
ETSI “Organizational interoperability, as the name implies, is the ability of organizations to effectively communicate and transfer (meaningful) data (information) even though they may be using a variety of different information systems over widely different infrastructures, possibly across different geographic regions and cultures. Organizational interoperability depends on successful technical, syntactical and semantic interoperability” (ETSI 2006, p. 6).
These definitions of organizational interoperability mix methods and standards for the technical linkage of business processes (process organization) with questions about the organization of support functions. Such support functions cannot be assigned to one level only because they are cross-sectional and therefore apply to all layers of interoperability. EIF 2.0 has not only failed to eliminate this mess, but also increased it by adding issues such as organizational relationship and change management (see next box). Organizational Interoperability in EIF 2.0 This aspect of interoperability is concerned with how organizations, such as public administrations in different member states, cooperate to achieve their mutually agreed goals. In practice, organizational interoperability implies integrating business processes and related data exchange. Organizational interoperability also aims at meeting the requirements of the user community by making services available, easily identifiable, accessible and user-focused. 1. Business process alignment In order for different administrative entities to be able to work together efficiently and effectively to provide European public services, they may need to align their existing business processes or even to define and establish new business processes. Aligning business processes implies documenting them, in an agreed way, so that all public administrations contributing to the delivery of European public services can understand the overall business process and their role in it. 2. Organizational relationships Service orientation, on which the conceptual model for public services is built, means that the relationship between service providers and service consumers must be clearly structured. This involves finding instruments to formalize mutual assistance, joint action and interconnected business processes in connection with cross-border service provision. Examples of such instruments are memoranda of understanding (MoUs) on joint actions and cooperation and/or service level agreements (SLAs) signed between participating public administrations. For cross-border action, they should preferably be multilateral agreement. 3. Change management Since delivering a European public service is the result of collective work parties that produce or consume parts of the service, change management processes are critical to ensure the accuracy, reliability and continuity of the service delivered to other public administrations, businesses and citizens. (CEC 2010a, Annex 2, p. 22)
3.6
Basic Idea for Re-conceptualization
Only the first of the three issues mentioned in the EIF 2.0 definition, the standards for business process alignment, is comparable to the standards assigned to the other layers and therefore can be categorized as an additional layer above semantic
3.6 Basic Idea for Re-conceptualization
59
interoperability. The other aspects, so far subsumed under the heading organizational interoperability, should be conceived as issues, which cut across and are related to all four layers similar to the legal aspects. In order to avoid misunderstandings we propose to abandon the term “organizational interoperability” and rather call the technical standards for business process alignment “business process interoperability” while summarizing the other aspects under the concept of “governance” A distinction between the “what” and the “who and how” of achieving interoperability has been proposed in the EPAN framework (EPAN 2004). Meanwhile also EIF 2.0 mentions “interoperability governance” and conceives it as a cross-cutting issue: Due to their cross-border and in some cases cross-sectoral characteristics, European public services operate in a complex and changing environment. Ensuring interoperability between legal instruments, organization business processes, information exchanges, services and components that support the delivery of a European public service is a continuous task, as interoperability is disrupted by changes to the environment, i.e., to legislation, the needs of businesses or citizens, the organization of public administrations, business processes or technologies (CEC 2010a, Annex 2, p. 28).
However, neither the EPAN Framework nor EIF 2.0 consider different governance structures for the different layers of interoperability: Protocols at the technical level are primarily defined by national and international standardization committees including Internet working groups. Data formats, ontologies, and other means of creating semantic interoperability are – due to their more concrete relation to a particular domain – mostly developed by industrial associations, professional bodies, and local government associations. Regulations concerning business process alignment are either directly negotiated by administrations involved or by superior administrative agencies via ordinances (Fig. 3.5). EIF 2.0 emphasizes the importance of interoperability governance and interoperability agreements but only vaguely concludes: Moreover, as the common components and interoperability agreements are the results of work carried out by public administrations at different levels (local, regional, national, EU) coordination and monitoring this work requires a holistic approach (CEC 2010a, Annex 2, p. 28).
This lack of clarity for how to establish a governance structure of interoperability is surprising in a document, which explicitly has been issued to provide guidance and coherence among NIFs of the Member States. This deficit may stem from the peculiar position of the European Commission with regard to the public sector of its Member States as well as the often-difficult relation between national government and lower level governments (state, regional and local) within each Member States. In this context, any proposal for coordination is likely to raise concerns and opposition. To a lesser degree, this problem applies to NIFs. Therefore, a re-conceptualization is called for in order to clarify the problem of governance of interoperability. At the time of writing this report, no classification of the different areas is available, in which standards for semantic and organizational interoperability are to be
60
3 Review of Prominent IFs and the Need for Re-conceptualization
Fig. 3.5 Layers of interoperability and their governance
negotiated and decided. The distinctions made between different modes of governance (hierarchies and networks as well as central authorities and federations) and different levels of governance (political and IT governance) in Sect. 2.3 may be applied here. But there is still a need for another differentiation. The EPAN framework defines Governance of Interoperability as being “concerned with the ownership, definition, development, maintenance, monitoring and promotion of standards, protocols, policies and technologies that make up the various elements of an interoperability architecture” (EPAN 2004, p. 11). This enumeration mixes the modes for coordination of selecting, negotiating and enacting standards on the technical, syntactic, semantic and business process layer with those for implementing and maintaining these standards for specific public services. Using a distinction by Scholl and Klischewski (2007): There are different configurations for how interoperability is established and for how interoperation is implemented and maintained. From studies of electronic data exchanges between industries, we learn that direct exchanges based upon standards are the exception rather than the rule. For example, in the exchange of electronic orders and invoices between retailers and manufacturers, the data are not supplied directly but rather transmitted via VANS (Value Added Network Suppliers) who collect the different orders from retailers for all of their suppliers, conduct formal quality checks and format conversions, and repackage the incoming orders for each supplier. Similar systems can be found in
3.6 Basic Idea for Re-conceptualization
61
electronic funds transfer between banks via clearing centers (Fig. 3.6) (see Kubicek and Seeger 1992; Kubicek 1993).
Fig. 3.6 Clearing centers as intermediaries
The study about back-office reorganization in e-government mentioned above proposed to call any kind of central provision of auxiliary services clearing centers (Millard et al. 2004, see also Kubicek et al. 2007). In the literature on e-commerce, the more abstract term “intermediaries” is used to describe the provision of functions such as electronic payment or authentication services (cf. Sarkar et al. 1995). An example of a clearing center in e-government is the Crossroads Bank for Social Security (CBSS) in Belgium (see case no. 4). This bank was established in 1991 for processing the social contributions from employers in Belgium to the different health insurance institutions. Instead of running a centralized database, CBSS only maintains registers about the location and type/format of the data agencies need and for whom and for which purpose these data can be accessed. The objective of the CBSS clearinghouse is therefore to identify and route data, regardless of their format. Thus, rather than being a large centralized database in its own right, it is a highly intelligent data exchange mechanism. In this case, the users are different employers, each of whom may have different data systems and formats, each of which needs to communicate with a variety of different social security institutions. While the interoperability standards for data exchange may be classified according to the four layers of interoperability, no classification concerning the functions, which may be provided by a clearing center, exists. One of the objectives of this research is to develop an empirically grounded classification, i.e., a taxonomy, of the range of options for establishing and maintaining interoperation in e-government.
62
3 Review of Prominent IFs and the Need for Re-conceptualization
Fig. 3.7 Enhanced interoperability framework
Therefore, to summarize, we propose that what is currently subsumed under organizational interoperability should be divided into three dimensions or views (Fig. 3.7): 1. “What” is standardized: the functional view, 2. “Who” develops and establishes these standards: the IT governance view 3. “How” interoperability standards are operated: the implementation view.
3.6.1
The Functional View – “What” Has to be Standardized?
As mentioned above, in line with the definitions of technical, syntactic, and semantic standards, this aspect of what so far is called organizational interoperability should be restricted to technical and functional standards for the multilateral alignment of business processes across organizational boundaries. Examples include standards for process modeling, architectures, or choreographies and standard languages for their specification and documentation. A prominent example is Service-Oriented Architectures. By using standardized business process definition languages, Service-Oriented Architectures allow for the common description of inter-organizational processes, such as Web services defined in WSDL
3.6 Basic Idea for Re-conceptualization
63
(Web Services Definition Language) or BPML (Business Process Modeling Language). In order to avoid misunderstandings caused by the multiple use of the attribute “organizational”, we suggest naming this layer “Business Process Interoperability”.
3.6.2
IT Governance (The Institutional View): “Who” Defines Standards?
Standards for interoperability are established in different organizational settings and by different institutional means. As mentioned above, no common governance structure for all layers of interoperability exists. Rather protocols at the technical layer and standards for syntactic interoperability are mostly defined by national and international standardization committees. E-government officials can participate in processes in order to influence the outcome according to their requirements. Data formats, ontologies, and other methods for creating semantic interoperability in contrast have to negotiated and agreed upon in existing public sectors and e-government bodies or in newly established configurations.
3.6.3
The IT-Service View: “How” Is Interoperability Implemented?
Once standards are selected, their implementation raises a lot of questions of how to organize and manage the effective operation and maintenance of the data exchange. As mentioned above, there may be good reasons for assigning certain functions to clearing centers within the public sector or to commercial providers of Value Added Networks in order to support the implementation of standards. The research presented in the following chapters was directed towards collecting more empirical evidence of how the two crosscutting perspectives, i.e., the IT governance view and the implementation view, have been addressed in goodpractice cases of interoperability in government. We hoped that the study would also help provide some clarification of what the governance of interoperability in government might look like. We scrutinized about 120 cases of public services, which were nominated or selected as good-practice case in achieving interoperability in e-government public services within EU Member States. The cases included at least two levels of government; i.e. national and regional, national and local, or regional and local. All cases pertained to services within a given EU member state but not between EU Member States. In the next chapter, we describe the method for case selection. Chapters 5–9 are dedicated to analyzing interoperability requirements, wants and needs of stakeholders, the implementation of interoperability, and IT governance.
.
Chapter 4
Selection and Classification of Case Studies
So far IFs and reference models have been developed by borrowing from more abstract models (e.g. OSI Reference Model) and by intuitive generalization from individual observations. They were meant to provide guidance for achieving interoperability and interoperation in e-government by structuring and classifying options for action, but they hardly met the methodological requirements for classification, in particular, completeness, unambiguousness, and discriminability. When using a stringent classification scheme, individual coders are expected to assign an objective to the same class. Applying a classification scheme to a sample group of objects serves as a test for inter-coder reliability. If doubts arise when assigning objects, the definition of the classes can be revisited and improved. In the social sciences a classification scheme, which has been empirically validated, is also referred to as taxonomy. The research presented in this report followed such a methodological approach. The general considerations for re-conceptualizing organizational interoperability and providing a more differentiated outline of governance of interoperability have been tested and validated by a sample of cases where interoperation has been achieved.
4.1
Case Selection
Of course, the significance of the results strongly depends on the selection of these cases. As the re-conceptualization addresses the European Interoperability Framework (EIF) and the National Interoperability Frameworks (NIFs) of EU Member States, the cases were to come from all over Europe. In addition, the cases were to represent a variety of interoperability scenarios and approaches, which were successfully completed. The cases subjected to empirical analyses as presented in the following chapters meet these requirements. They were selected and documented in two previous H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_4, # Springer-Verlag Berlin Heidelberg 2011
65
66
4 Selection and Classification of Case Studies
studies for the European Commission, in which the first two authors of this report were also involved as mentioned before. In a study on good practice in back-office reorganization in e-government, 29 cases were selected in a three-stage process (Millard et al. 2004). The goal of the study was to contribute to the Commission objective to offer online access to the 20 governmental reference services. Therefore, cases of successful back-office reorganization relating to these services had to be identified in the 15 Member States (at that time) plus Norway and Iceland. This was achieved with the help of national experts in each country, who looked for national and European award winners and other acknowledgements of good practice and checked the case websites. Finally, 29 cases were selected for further study. Via personal interviews more data were collected on a number of predefined aspects, including interoperability and others. In 2004, the European Commission published a tender for a larger study on interoperability. The study was chartered to survey the state of interoperability in all Member States including barriers and success factors, and again would collect cases to be published in the Commissions’ good-practice portal developed to disseminate the e-government activities of the Commission, mentioned in the introductory chapter. The European Institute of Public Administration (EIPA) in the Netherlands, the Centre for Research and Technology Hellas/Informatics and Telematics Institute (CERT/ITI) in Greece, and the Institute for Information Management Bremen (ifib) in Germany won the bid for this study. The first two authors of this report, working for ifib within the consortium, were responsible for collecting the good-practice cases and to document them according to a template defined by the Commission. In this context, a good-practice case was defined by nomination from a jury of experts for one of the e-government awards of the European Commission 2001, 2003, or 2005 or by nomination from national experts in one of the Commission’s working groups on e-government. Therefore, a list of several hundred experts had to be compiled and a short questionnaire was sent to these experts asking for the nomination of valuable interoperability cases in their country. From these two sources, about 100 cases of good practice were identified. The information provided in these surveys was not always consistent with the reasons given for their nomination. A few had been nominated in a planning stage but were never completed; others did not include interoperation between different systems but only dealt with the development of a single system by one organization. In addition, a few cases were added to the list from the EU-funded TERREGOV project, which was also to collect cases of good practice of organizational interoperability (Bousson and Keravel 2005, see also http://www.terregov.eupm.net), and from the above mentioned back-office study. In all, interoperability profiles for about 120 cases have been produced and published. Short questionnaires were sent to the case owners asking for more information and the validation of profiles with a return rate of about 70%. Based on this, 77 cases ultimately provided valuable information on good practice in interoperability and were eligible for further analyzes. For 18 of 77 cases additional interviews were conducted highlighting certain aspects of
4.2 Case Distribution Table 4.1 Sources and selection steps of cases Source Back-office eEurope award study good-practice cases 2001/2003/2005 Total number of 29 62/67/52 cases Number of IOP17 10/39/14 related cases Number of validated 16 1/20/9 IOP-cases IOP cases, long 2 0/0/7 version
67
Terregov study
National Total nominations
10
65
285
6
33
119
6
25
77
0
9
18
interoperability, e.g., centralization vs. standardization, or semantic interoperability. These cases were presented and discussed in eight workshops with 30–40 e-government experts from different Member States. The case descriptions were published on the Commission’s good practice portal and later shifted to the newly created epractice portal (http://www.epractice.eu). In addition, the cases have also been made available in a special database (http://www. egov-iop.ifib.de), and are searchable by certain indicators. Table 4.1 shows the sources and selection steps of the case sample of this study. The titles and case owners of the 77 cases are listed in Annex 1. For the profiles of all 119 cases and the 18 long versions see http://www.egov-iop.ifib.de. In Annex 2, cases, which are mentioned as examples for certain aspects or discussed in different sections of this report, are shortly summarized. We numbered these cases for easy referencing.
4.2
Case Distribution
As mentioned in the introduction, interoperability is required and provided in a number of different contexts. • The primary sample consists of cases of online delivery of a specific governmental service to citizens or business that requires collaboration between different units or that has to be offered by different units in the same way by agreeing on certain standards. Examples for such specific public services are compiled in the reference list of the European Commission reproduced in Table 1.1 in the introductory chapter. • The secondary sample encompasses cases of integration, in which previously separated systems have been integrated to form a new one, i.e., where some kind of centralization has been conducted, which did not need any interoperability between its parts but only common interfaces to other systems.
68
4 Selection and Classification of Case Studies
Table 4.2 Frequency of distribution of cases Sample Specific services Integration 77 31 17
Infrastructure 6
Portal 23
• Other cases did not start with a particular service, but rather began with some kind of infrastructure, on which several services would be provided later on. • And finally there are cases, where a portal was developed to provide access to several previously existing services. Table 4.2 shows the frequency distribution of the four kinds of cases. This is not a classification in the sense mentioned above. Some of the cases collected could be assigned to more than one category because they were part of a larger initiative. Sometimes a service has been developed in a way that the facilities may also be employed for other services later on. In other cases, a platform might provide several services but only one case has been submitted and described in detail. The eventual assignment of cases in this study therefore only describes the focus and depended on what grounds it was nominated by national experts or what information was submitted for the eEurope awards. Hence the figures do not indicate a generalizable frequency of different kinds of systems but the respective foci within a more complex and dynamic landscape. Some of the analyses in the following chapters only make sense for the classical case of interoperability for the provision of dedicated services. Therefore they are treated as a sub-sample, where appropriate.
4.2.1
Distribution by Country
The 77 cases were taken from 23 different Member States. Table 4.3 shows the frequency distribution across countries. It does not correspond to the size of the countries or to their ranking in the e-government benchmarking. As can be concluded from the description of the selection process; inclusion rather depended on the engagement of national representatives in submitting cases to eEurope awards and in responding to the survey conducted. Therefore, the analyses based on this sample cannot claim to be representative for e-government in Europe. Rather, they only allow for an exploratory analysis, the results of which might be validated by a representative sample, if required. Along with the country distribution of all 77 cases, Table 4.3 also shows the distribution of the sub-sample of specific services cases.
4.2 Case Distribution
69
Table 4.3 Distribution of good-practice cases by country Country All 77 cases AT BE BG CH CZ DE DK EE ES FI FR GR HU IC IE IT MT NL NO PL RO SE UK Total
4.2.2
Frequency 9 3 1 1 1 7 6 1 6 4 3 1 1 1 2 10 2 3 2 2 1 3 7 77
Percent 11.7 3.9 1.3 1.3 1.3 9.1 7.8 1.3 7.8 5.2 3.9 1.3 1.3 1.3 2.6 13.0 2.6 3.9 2.6 2.6 1.3 3.9 9.1 100.0
31 specific services Frequency 4 1 0 1 0 3 4 0 2 2 2 0 0 0 1 4 0 1 0 2 0 2 2 31
Percent 12.9 3.2 0 3.2 0 9.7 12.9 0 6.5 6.5 6.5 0 0 0 3.2 12.9 0 3.2 0 6.5 0 6.5 6.5 100.0
Distribution by Level of Government
E-government services are offered by agencies at different levels of government, i.e., local, regional, or national. In some cases several local or regional agencies got together and jointly developed an e-service. Table 4.4 shows the distribution of cases across the different levels of government. Almost 60% of the cases deal with services provided at the national level but requiring some kind of interoperability with regional and/or local agencies.
4.2.3
Disclaimer
We might claim that the cases, on which this research is based, cover a wide range of the diversity of interoperability. But one important disclaimer has to be made. They are all considered to be cases of good practice, i.e., successful in some sense. Therefore they do not qualify for an analysis of barriers, problems, side effects, and
70
4 Selection and Classification of Case Studies
Table 4.4 Distribution of good-practice cases by level of government Level of service All 77 services 31 specific services provision Frequency Percent Frequency Percent National 46 59.7 25 80.6 Multiregional 4 5.2 1 3.2 Regional 15 19.5 4 12.9 Multilocal 5 6.5 1 3.2 Local 7 9.1 0 0 Total 77 100.0 31 100.0
not even for the identification of success factors, because such an analysis requires a comparison between more or less successful projects or between successful and unsuccessful projects. But for the conceptualization of organizational interoperability and the classification of measures and options it is appropriate to look at successful cases only and to learn from them.
4.3
Coding of Cases
In the following chapters several scales for the issues under investigation are presented and tested. These scales have been constructed from a qualitative review of the sample and then been applied to the cases by coding. Coding in this context means assigning a scale value to each individual case. Assigning the same value to two cases means they were found similar in this respect, assigning two different values means they show relevant differences. This was not a process of objective measurement but rather a process of interpretation and associations. The terms used to define the values might have been understood differently, or the people coding might have read a case description with different foci. Therefore for each scale, two individuals independently coded the cases. Values were compared and variances discussed. For some scales, as a result of this discussion, the definitions of the values were revised. For Chaps. 5, 7–8, and 9, coding was done by the second author and a Master’s student involved in the project. For Chap. 6, cases have been coded by the second and the third author of this report.
Chapter 5
Interdependencies in E-Government and Their Interoperability Requirements
As outlined in the introductory chapter, only few governmental services are completely provided by a single organizational unit employing only a single IT application. In many cases a service relies on data provided by other applications within the same agency or provided by other agencies on the same or on different governmental levels (local, regional, national). This is due to the established division of labor in the public sector, which has emerged for historical, legal, or political reasons. For gaining efficiency or for increasing customer convenience, this division of labor might be virtually overcome by integrating the different processes. There are different kinds of integration, in response to different kinds of interdependencies between the units involved.
5.1
Horizontal and Vertical Integration
As in industrial organization quite often businesses processes are composed of several workflows, which are assigned to different organizational units. Figure 5.1 shows some patterns of existing division of labor, employing the concepts of services and stages as well as horizontal and vertical integration. A service may be defined as a public e-service experienced by the user (whether individual or business) that directly serves an ultimate user objective. As mentioned earlier in the European benchmarking studies, the list of 20 basic public services for citizens and for businesses quoted in the introductory chapter has been used (Table 1.1). A stage is a defined workflow within one organizational unit, which either completely provides a service or only partially contributes to its provision. The study on back-office reorganization for the European Commission (Millard et al. 2004; see also Kubicek et al. 2007) mentioned earlier employed these concepts and distinguished four different constellations (Fig. 5.2). A one-stage service is, for example, the request and delivery of a birth certificate from a local registry. An example of a multi-stage service is the request for H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_5, # Springer-Verlag Berlin Heidelberg 2011
71
72
5
Interdependencies in E-Government and Their Interoperability Requirements
Fig. 5.1 Different types of integration of services and stages
Fig. 5.2 Multi-stage and service combination
a passport put to the local government, which has to be forwarded to a national agency producing the passport, and the example of the redesigned application for child allowance in Ireland (Fig. 1.3 in Chap. 1). Of course, complexity increases with the number of stages and the number of offices involved. From a technical point of view, the ideal case is where the technical systems of different back offices are integrated in such a way that incoming data are processed automatically and the result is forwarded to the back office in the next stage, until the service is delivered online to the customer via a front office by offering different communication channels. However, for reasons of equitable judgment or of security, human intervention may still be required, thus interrupting the electronic process chain. The integration of several stages metaphorically is called vertical integration. In contrast horizontal integration refers to the integration of two or more different services on the same level of the supply chain. Most frequently mentioned is One Stop Government, i.e., the integration of a couple of services that are usually requested in combination due to a certain life situation or for other reasons and that make use of the same basic data (see Hagen and Kubicek 2000). In order to increase benefits or convenience for the customer by having him to enter his data only once,
5.2 Different Types of Interdependence
73
as well as to reduce the cost of processing multiple data, the integration of two or more services using the same data is promising. This is also true for Portals and calls for technical and organizational integration and/or standardization. This classification comes close to the four stages model of e-government proposed by Layne and Lee (2001). The two authors predicted progress along the stages of (1) catalogues, (2) transactions, (3) vertical integration and (4) horizontal integration. We cannot confirm a common sequence for stages (3) and (4), but rather find cases in our sample where horizontal integration is aimed at without having vertical integration already achieved. At this point we only maintain that horizontal and vertical integration lead to different interoperability requirements.
5.2
Different Types of Interdependence
The concept of vertical integration is still very broad and covers different cases of interdependence, which should be distinguished more clearly. In organization theory in the late 1960s and early 1970s the choice of coordination mechanisms was related to the technology of an organization and the resulting interdependencies between sub-units. In particular, Thompson (1967) distinguished three kinds of interdependence, which can be handled with different modes of coordination: sequential, reciprocal, and pooled interdependence (Fig. 5.3). Sequential interdependence arises when a process directly depends on the output of another process. Unit B can only achieve its task if Unit A has fulfilled its task and has delivered its output in an expected format. In the context of back-office integration, sequential interdependence exists between back offices providing different stages of a service. According to the kind of service, there may be only a single chain consisting of two or more stages with only one office for each stage. Or there may be several offices for one stage, responsible for the same tasks but for different geographical
Fig. 5.3 Different types of interdependence
74
5
Interdependencies in E-Government and Their Interoperability Requirements
areas, customer groups or other criteria. Of course, the latter case is more complex than the former one. We may speak of bi-lateral and multi-lateral sequential interdependence in order to catch this difference. While sequential interdependence results from a one-directional supply chain, there are also cases where two units mutually rely on each other, e.g., because they have to check different requirements for the same permit. These cases have reciprocal interdependence. While sequential interdependence and reciprocal interdependence refer to functional and/or time-related interdependencies between workflows among the backoffices involved, a less intense form of interdependence arises when two or more processes depend on shared resources. Thompson calls this pooled interdependence, and uses it to refer to pooled personal or financial resources within one organization. However, in the context of back-office integration and interoperability in e-government the dependence on a pool of data is most relevant, in particular registers and directories, which have to be kept up to date. Each back office within a group of similar or different agencies can fulfill its task only if it has access to up-to-date data.
5.3
Different Types of Interoperability Requirements
Looking at sampled good-practice cases we can easily identify those with sequential interdependence and requiring interoperability between units in different stages of a multi-stage service provision. We also find cases with pooled interdependence where different services make use of the same database or files. However, there are two other kinds of cases with slightly different interoperability requirements. To completely reflect these differences, we distinguish four different kinds of requirements that may demand different kinds of measures for achieving interoperation. These four classes of cases require interoperability for the exchange of: • • • •
Common data for different services (multi-service exchange) Workflows between different stages of a service (multi-stage exchange) Data between units in different geographical areas (multi-area exchange) Common services for different files (multi-file exchange)
5.3.1
Multi-service Exchange
Quite often different public services require the entry of the same data. A single entry point and perhaps even a common file can reduce cost and errors and at the same time improve user friendliness. However, this requires a standardization of data and corresponding interfaces of the different services making use of these shared data (Fig. 5.4).
5.3 Different Types of Interoperability Requirements
75
Fig. 5.4 Multi-service exchange
This is the classical one-stop government/single sign-on case. Here, a single point of contact is established that provides access to several public services. An example for this interoperability requirement is given by the company registration e-service in Sweden (see case no. 5). The e-service provides a one-stop shop for electronic registration at one place instead of filing paper forms with two separate authorities. By entering the company registration information in the website (foretagsregistrering.se) the data is sent in parallel to the Swedish Company Registration Office (Bolagsverket) and the Swedish Tax Agency (Skatteverket) (right part of Fig. 5.4).
5.3.2
Multi-stage Exchange
Public services, which are provided by a multi-stage supply chain, require interoperability between different stages (Fig. 5.5).
Fig. 5.5 Multi-stage exchange
An example for this interoperability requirement is given by the child benefit service in Ireland (see case no. 1) mentioned in the introductory chapter (Fig. 1.3). In this case, interoperability had to be achieved in a sequential manner between the maternity hospitals and the civil registration at local and national level as well as between the national civil registration and the child benefit section.
76
5.3.3
5
Interdependencies in E-Government and Their Interoperability Requirements
Multi-area Exchange
Government agencies below the national level are frequently organized according to geographical or territorial areas, resulting in still another kind of interoperability requirements whenever there is the national goal of equity for all citizens or customers. Then interoperability is required between agencies of the same kind in different geographical areas providing the same service for their respective customers in each area. This may cause reciprocal interdependence if each unit has to send and receive certain data, or in pooled interdependence if they all have to rely on the same database (Fig. 5.6).
Fig. 5.6 Multi-area exchange
An example for this kind of interoperability requirement is given by the change of address service in Germany (see case no. 3) mentioned in the introductory chapter. As in many European countries, the local civil registration offices are responsible for the maintenance of up-to-date civil registration data. When a citizen moves, his or her address data must be exchanged bi-laterally between the “old” and “new” civil registration authorities, and hence interoperability among the many decentralized civil registration authorities had to be achieved. An alternative solution for the same objective in Austria is shown in Fig. 5.7. Local registration offices send standardized messages to a newly established central register of residence (CRR). While the organizational requirements differ in both cases, technical standardization is equally required (see case no. 6).
Fig. 5.7 De-centralized and centralized registers in Austria
5.3 Different Types of Interoperability Requirements
5.3.4
77
Multi-file Exchange
There are also cases where similar services are offered for technically different but related files and where cost reduction and an increase of user-friendliness can be achieved by developing a shared service across different files, in particular search functions or forwarding services (Fig. 5.8).
Fig. 5.8 Multi-file exchange
An example for this kind of interoperability requirement is the bibliotek.dk service (see case no. 7) that enables a user to access the complete catalog of books in all Danish libraries. Books can be located and picked up via a meta-search function across all open access catalogues (OPAC) of all Danish libraries via the Internet from any place.
5.3.5
Distribution in Case Sample
Table 5.1 shows the distribution of the different interoperability requirements for all surveyed good-practice cases and for the sub-group of the specific-service cases. As a case could be characterized by more than one interoperability requirement, the sum for each line is higher than the number of cases (n ¼ 77 for all cases and n ¼ 31 for the specific-service cases). Table 5.1 Interoperability requirements in case sample IOP requirements Horizontal Vertical integration ¼ integration ¼ multi-service multi-stage exchange exchange All cases 24 49 Specific services group 7 23
Geographical cooperation ¼ multi-area exchange 12 3
Shared directories ¼ multi-file exchange 9 3
78
5
Interdependencies in E-Government and Their Interoperability Requirements
The table shows that all four kinds of interoperability requirements are well covered by the sample. In the whole sample as well as in the sub-sample, vertical integration is the most frequent. When analyzing the measures taken to achieve cooperation and interoperation we will check whether different kinds of interoperability requirements were met by different kinds of technical and/or organizational integration and/or standardization.
Chapter 6
Wants and Needs When Pursuing Interoperability
When establishing requirements for interoperability, the traditional approach endeavors to employ a perspective of objectifiable or technical needs. An actorcentric view on interoperability requirements, which also regards subjective wants and needs of main actors engaged in an e-government project, would hence complement the traditional perspective. Scholl and Klischewski (2007, p. 904) suggest such an actor-centric research approach, which they call the wants-and-needs approach or needs-theoretical perspective. While the authors consider needs to be ‘objectively valuable’, such as basic survival or safety, wants, in contrast, are socially conditioned and culturally flavored. However, in the e-government context we are also concerned with institutional actors, i.e., human actors who act on behalf of organizations. Institutional needs and wants root in specific tasks and purposes as well as the overall mission of an institution. Yet these institutional wants and needs are perceived and expressed differently by different individuals who act on behalf of an institution. So, whenever leaders of similar agencies across different geographical areas have to agree upon a common electronic service, they may do so based on different wants and needs. Scholl and Klischewski (2007) distinguish between permanent or recurring wants and needs, occasional wants and needs as well as ad hoc wants and needs. Furthermore, the authors suggest analyzing interoperability along the following four dimensions: • The governance dimension (referring to basic democratic principles such as the division of powers and a system of checks and balances); • The economic dimension (regarding the cost of interoperability and interoperation and the expected benefits both short-term and long-term); • The organizational dimension (alluding to intra- and inter-organizational requirements); and, • The technology dimension (regarding technology requirements and standards). In each dimension wants and needs might be similar or even common to different agencies while others might be domain or purpose-specific. For example, local governments in a greater geographical area might coordinate their emergency H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_6, # Springer-Verlag Berlin Heidelberg 2011
79
80
6 Wants and Needs When Pursuing Interoperability
and disaster response management addressing their shared economic wants and needs, while the respective local police forces, fire brigades, and other services would continue to serve local and domain-specific needs. Based on their review of the literature Scholl and Klischewski (2007) concluded that still little was known about the most salient wants and needs regarding interoperability within e-government projects and encouraged further case studies across all branches and levels of government to that extent. We followed up on this proposal and analyzed 19 cases of those introduced in Chap. 4. We found that these cases had a rich enough documentation to lend themselves to an in-depth study incorporating the wants-and-needs approach. From the data we inductively developed a list identifying more than 30 permanent and occasional institutional wants and needs. In addition, we also analyzed the success measures applied, the principles followed, and other aspects. We will discuss those results in a separate publication. In this chapter we focus on permanent and other wants and needs. Figure 6.1 depicts the frequency of identified permanent wants and needs. Most often project managers and case owners mentioned “service enhancement” (16 out of 19), “secure and reliable data and transaction processing” (14 out of 19) and “effective data collection and exchange” (14 out of 19). Interestingly, “cost reduction” was mentioned in far fewer cases (6 out of 19) and software reusability even more rarely. In Table 6.1 we present the frequencies of occasional, ad hoc needs as well as general and specific purposes of creating interoperability. “Modernization of administration” was mentioned in all cases; “developing and maintaining an effective and efficient IT infrastructure” and “intergovernmental collaboration” were
Fig. 6.1 Permanent wants and needs (n ¼ 19)
6.1 Interoperability Requirements
81
Table 6.1 Frequency of selected wants and needs (n ¼ 19) Occasional wants and needs Ad-hoc wants and needs Paper reduction 15 Legacy systems integration 16 Streamline and simplify processes 14 Enhance public reputation and visibility 2 Process harmonization and integration 12 Deploying new services 9 Specific purposes General purposes Modernization of administration 19 Effective, lean, and agile service to the 15 public Developing and maintaining an effective 18 Improved regional competitiveness 2 and efficient IT infrastructure for public service Intra-governmental collaboration 15 Sustainable regional development 1 Inter-governmental collaboration 17
next in frequency. It is also interesting to note that in 16 of 19 cases “legacy system integration” was an institutional want and need while in only 9 cases a want and need for “developing new services” was recorded.
6.1
Interoperability Requirements
First, we looked at the most frequently mentioned occasional wants and needs in a cross-tabulated fashion, i.e. relative to interoperability requirements. As shown in Table 6.2, the four effectiveness/efficiency-related occasional wants and needs (time savings etc., effective data collection, streamline etc., and paper reduction) were highly pursued in cases of both multi-service and multi-stage integration. For example, in projects striving for multi-service integration, “paper reduction” was found in all cases, “streamline and simplify business processes” in almost 90% of Table 6.2 Effectiveness over requirements Interoperability Time savings, workflow requirements reduction, speeding up processes, reducing red tape Multi-service 6 67% Multi-stage 8 67% Multi-area 2 40% Multi-file 1 100% n 12
Effective data collection and exchange
Streamline and Paper simplify business reduction processes
6 9 3 1 14
8 10 4 0 14
67% 75% 60% 100%
89% 83% 80% 0%
n
9 100% 9 10 83% 12 3 60% 5 0 0% 1 15 19
the cases, and “time savings” and “effective data collection” were identified in twothirds of these cases. Interestingly, although at slightly lower percentages, the rank order of these occasional wants and needs would remain the same when compared to projects dealing with vertical integration, i.e., multi-stage interoperation. In cases
82
6 Wants and Needs When Pursuing Interoperability
of multi-area exchange, “streamline and simplify business processes“ was mentioned most frequently. Table 6.3 shows the cross tabulation of interoperability requirements with “soft,” i.e., not easy to measure wants and needs. “Geographic location identification” was most frequently mentioned in cases dealing with multi-area exchange. Since these projects aim at standardizing processes and exchanges across different areas, it was not surprising that “Regional attractiveness and competitiveness” was not mentioned as a want and need. “Enhancing public reputation” as a want and need is only mentioned in the directory (multi-file) case. We reason that interoperability projects and multi-agency collaboration might not have been seen as the best vehicles for enhancing an agency’s or government’s public reputation and visibility. Table 6.3 “Soft” wants and needs over interoperability requirements Interopera-bility Geographic location Regional attractiveness Enhance public n requirement identification and competitiveness reputation and visibility Multi-service 2 2 1 9 Multi-stage 0 3 1 12 Multi-area 3 0 0 5 Multi-file 0 0 1 1 n 3 3 2 19
When analyzing the technical wants and needs, we found a strong tendency to integrate legacy systems into the overall interoperability efforts and also to standardize on the basis of open standards. As Table 6.4 shows, “legacy system integration” was pursued in the vast majority of the projects. The standardization on basis of open standards was not pursued quite as strongly as legacy systems integration, particularly, with regard to multi-service (horizontal) and multi-stage (vertical) integration. At this time, we can only speculate why open standards played a slightly lower role in projects at the multi-service and multi-stage levels than at multi-area and multi-file levels. However, it appears worthwhile to investigate the proliferation of open standards in projects requiring interoperability at a future point in time again. Table 6.4 Standardization and legacy integration over requirements Interopera-bility Open standards alignment and Legacy systems requirements standardization integration Multi-service 5 8 Multi-stage 5 10 Multi-area 5 5 Multi-file 1 1 n 12 16
n 9 12 5 1 19
6.3 Summary
6.2
83
Levels of Government
Since some interoperability initiatives were carried out at local and also at regional levels, we were curious to see whether or not we would find any major differences between the various levels of government. We expected to find some differences between the levels of governments in the area of effectiveness/efficiency (“service enhancement,” “secure personal identification,” “secure and reliable data and transaction processing,” “paper reduction” as well as “time savings etc.”). However, while the occasional wants and needs differed between the various levels of government, these differences were not of any order of magnitude in the area of effectiveness/efficiency. Yet, with regard to the “soft” wants and needs, the differences between the government levels became more significant. Table 6.5 shows the distribution across levels of government for “soft” wants and needs such as innovation, image and autonomy, regional competitiveness, and sustainable development. Innovation in the form of new services was mentioned in all four cases at the regional level and not once at the national level nor in cases of multi-regional collaboration. The two multi-regional cases focused on introducing open standards. It is also noteworthy that improved regional competitiveness and sustainable development were only mentioned in one of four regional cases. Table 6.5 “Soft” wants and needs by level of government Levels of Deploying Regional Open standards Improved Sustainable n government new attractiveness alignment and regional regional and service services and standardization competitiveness development competitiveness National Multiregional Regional n
6.3
5 0 4 9
1 0 2 3
9 2 1 12
1 0 1 2
0 0 1 1
13 2 4 19
Summary
While objectifiable technical and organizational necessities have been considered in technology-related projects including interoperability projects for a long time, the actor-centric perspective focusing on individual and institutional actors’ wants and needs has traditionally not been regarded to the same extent, if any. Following Scholl and Klischewski (2007) in our analysis, we introduced this complementary perspective to this study, which produced a number of interesting new insights: From 19 well-documented cases we found that in the vast majority of cases (1) service enhancements, (2) secure and reliable data/transaction processing, (3) effective data collection and exchange were the three foremost permanent wants and needs expressed by individual and institutional actors. Interestingly, wants/
84
6 Wants and Needs When Pursuing Interoperability
needs like (4) time savings/streamlining, (5) ease of use and handling, and (6) standardization/open standards ranked high, but not highest, nor did the usual “suspect” of cost reduction. Since wants and needs play a major role in striving for interoperability, we were able to also demonstrate that a sole focus on the objectifiable requirements might neglect other important influencing variables, potentially leading to unforeseen actions on part of major stakeholders who might feel misrepresented or even disregarded in the respective decisions. We finally found that analyzing the various wants and needs relative to purposes and requirements as well as to levels of government and layers of interoperability provided important insights with respect to actors/stakeholders’ specific emphases and expectations. As mentioned before, we will share more detailed insights in this context in a separate publication.
Chapter 7
Layers of Interoperability
In Chap. 3 we have shown that interoperability frameworks (IFs) similar to the ISO Reference Model for Open Systems Interconnection assign different standards for data exchange to three or four different layers of interoperability, which build upon each other. For our re-conceptualization we have proposed a four-layer framework (Table 3.5 and Fig. 3.7). In this chapter we illustrate the standards on the layers of technical, syntactic, and semantic interoperability by examples from our case studies in Sect. 7.1 and further elaborate our redefinition of organizational interoperability in Sect. 7.2. On this basis we also take a look at the relationship between the four layers. The OSI Reference Model clearly assumes that standards on the different layers built upon each other, i.e., that standards on lower levels provide necessary services for functions on the next higher level, and that a standard at a higher level only function if standards from the lower layers are implemented. For the layers of interoperability this is assumed but not yet assessed empirically. In Sect. 7.3 we conduct such a test by applying a method of scalogram analysis from empirical social science research.
7.1
Technical, Syntactic and Semantic Interoperability
As shown in Chaps. 2 and 3 most IFs adopt a three-layer structure distinguishing technical, semantic and organizational interoperability. We have adopted the more differentiated four-layer model developed by the European Telecommunication Standards Institute (ETSI) which introduces the layer of syntactic interoperability above technical interoperability.
H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_7, # Springer-Verlag Berlin Heidelberg 2011
85
86
7 Layers of Interoperability
7.1.1
Technical and Syntactic Interoperability
Technical interoperability according to the EIF . . . covers the technical issues of linking computer systems and services. It includes key aspects such as open interfaces, interconnection services, data integration and middleware, data presentation and exchange, accessibility and security services (European Communities 2004, p. 16).
This definition includes standards and protocols from all seven layers of the OSI reference model (see Table 2.1) and much more. This may be criticized or accepted from a technical point of view. The European Telecommunication Standards Institute (ETSI) works with a more narrow definition of technical interoperability and introduces the additional layer of syntactic interoperability for a simple reason: ETSI is a developer of standards for technical interoperability but only a user of standards for syntactic interoperability. This is an important point for the analysis of governance: Standards for technical and for syntactic interoperability are negotiated and issued by different institutions according to different rules and regimes. A framework that does not distinguish between these standards cannot provide much guidance. According to ETSI technical interoperability . . . is usually associated with hardware/software components, systems and platforms that enable machine-to-machine communication to take place. This kind of interoperability is often centered on (communication) protocols and the infrastructure needed for those protocols to operate (ETSI 2006, p. 5).
As explained in Chap. 2, ever since TCP/IP became available and widely accepted, technical interoperability no longer presented any relevant barrier to interoperation. For some years a basic set of protocols has evolved for the communication between back offices of separate government units, in particular, Internet protocols for secure data transmission, e.g. HTTPS (Hypertext Transfer Protocol Secure), for e-mail e.g. SMTP and SMIME (Simple Mail Transfer Protocol/Secure Multipurpose Internet Mail Extensions), and, for file transfer, FTP (File Transfer Protocol) and SSL (Secure Socket Layer). Depending on security or performance requirements, government agencies have several options for internal and external data exchanges with regard to this layer of network/transmission service, for example, the (open and unsecured) Internet, or a virtual network (VPN ¼ Virtual Private Networks), or even a physical extranet such as the secure European administration network s-TESTA. Some Member States have developed enhanced services for secure data transmission including digital signatures. Germany has developed OSCI-Transport (Online Services Computer Interface). The Road Traffic Accident Automation Project in the UK (see case no. 8) is a good case for illustrating interoperability efforts related to the technical layer. In this e-service, the electronic transfer of data between the Compensation Recovery Unit of the Department of Work and Pensions and the Department of Health for the
7.1 Technical, Syntactic and Semantic Interoperability
87
compensation of victims of road accidents has been automated by employing the above-mentioned Internet protocols for secure data transmission. Another example is the Customs Declaration System CELINA in Poland that enables traders to submit their customs declarations in electronic form via the Internet (see case no. 9). The system includes a central repository of documents, the local application layer of the local customs offices, a jointly used payment system and the infrastructure for the use of digital signatures. Again, these functions build on Internet protocols such as HTTP with SSL and SMTP. Every trader or intermediary can send declarations from any device using a dedicated website or an email with attachment. Very often the power of the protocols on the technical layer is overestimated. Technical interoperability only guarantees the correct transmission of bits but does not tell anything about the meaning of these bits and what they represent, not even whether it is voice, video, or data. This is the task of standards on the syntactic layer, which define the syntax of particular services. According to ETSI syntactic interoperability . . . is usually associated with data formats. Certainly, the messages transferred by communication protocols need to have a well-defined syntax and encoding, even if it is only in the form of bit tables. However, many protocols carry data or content, and this can be represented using high-level transfer syntaxes such as HTML, XML or ASN.12. Generally, ETSI is a user rather than a definer of generic syntaxes with a few notable exceptions, such as the definition and use of Concrete Syntax Notation (CSN) in the GSM specifications. (ETSI 2006, p. 5)
While the syntax of SMTP only allows for a distinction between a header and a body of a message, standards like XML or EDIFACT provide more differentiated structuring of the content of a message by defining not only the beginning and end of each message in a batch but also the end and the type of each data field. However EDIFACT and XML only provide the syntax for constructing message types with different content such as orders, applications, invoices, etc., which belong to the semantic layer. From a technical point of view the more recent XML syntax is considered to be more powerful and flexible. From a governance point of view however, the change from a well-established standard to a new one within a network of autonomous users is even more difficult to manage than the first introduction of a common data exchange format. Therefore quite often a conversion service is employed instead of a complete migration of all participants. In the road traffic accident automation project the transfer of the compensation forms is based on XML, while the invoices and other information is exchanged according to the EDIFACT syntax. Another example is the change of address service in civil registration in Germany. For the exchange of deregistration data between the local registration offices a national standard X-Meld has been developed using XML schemes. Basically, each message exchanged in the service consists of two parts: the reference data (utilization data) and the content-related data (data content). Both parts are XML documents and the latter is in OSCI-XMeld format, which is the standard for the description of the content-related data within the civil registration.
88
7 Layers of Interoperability
Messages are transferred between the civil registration authorities using OSCI Transport, which is the standard for the secure exchange of messages between public authorities in general. A similar case is lomake.fi, the central Finnish portal for electronic forms in the public administration (see case no. 10). While a private company maintains the portal, public authorities use it to provide their services to citizens and businesses. The form portal is also integrated in the Finnish public-sector service portal suomi.fi. Public authorities interested in providing their online services through the form portal can integrate it into their workflow by technically linking their systems via standard Internet protocols. The portal offers more than 800 forms of 20 different public sector organizations. Figure 7.1 illustrates a linked system providing technical and syntactic interoperability. One concrete application is crime declaration to local police offices. Citizens enter a crime declaration via a web interface. Data captured in PHP are transformed into XML format. A police server checks every 10 min whether new declarations have come in, downloads them by FTP, and forwards them within the police VPN to the next police station responsible for dealing with the case. Moreover, data integrity, logical checks, conversion to XML file, temporary storing, timestamps, confirmation of application reception, etc. are done by common tools of the lomake.fi service. Lomake.fi can be seen as a typical clearing center that enables technical and syntactic interoperability between public authorities and their customers on a central level independent of a specific service application or the meaning of the data exchanged.
Fig. 7.1 Technical and syntactic interoperability in lomake.fi case (Source: own illustration, adapted from Millard et al. 2004, Vol. 3, p. 92)
7.1 Technical, Syntactic and Semantic Interoperability
7.1.2
89
Semantic Interoperability
Whereas syntactic interoperability provides for the exchange of clearly defined classes of data, semantic interoperability enables the automatic recognition of the individual data exchanged. In computer science, syntax refers to the grammar and formal rules for defining sets of data, while semantics define the meaning and the use of these data (Woods 1975). In other words, on the semantic layer data becomes information. Only if the semantics of data sets are defined and shared can these data be processed in one system, sent to another system, and there be automatically recognized and processed further. According to the EIF, semantic interoperability . . . is concerned with ensuring that the precise meaning of exchanged information is understandable by any other application that was not initially developed for this purpose. Semantic interoperability enables systems to combine received information with other information resources and to process it in a meaningful manner. (European Communities 2004, p. 16)
For example, electronic invoices sent from a supplier’s computer system are automatically recognized, compared to the delivery notification by the customer, and further processed in the accounting system of the customer, by identifying the date of the invoice, its number, and the amount to pay. This requires a common definition for each data in every field of a data set. International bodies have developed common definitions for a few data related to the import and export of goods (e.g. dates, telephone number, country ID), in particular UNCTAD (United Nations Conference on Trade and Development). For example there is UPC (Universal Product Code), a classification scheme for goods, but there are also several competing product codes such as the European Article Number printed as a barcode on many brand articles, the ISBN for books, and hundreds of national branch-related product codes. In these cases, the data exchange format provides two data fields, one for the code of the code applied and another one for the attribute of the object according to the selected code. While in e-business the problem lies in the diversity and heterogeneity of existing and often competing codes, for e-government there are only few national codes for services and the content of the respective application forms. A common data model of a service contains many more objects and attributes than an identifier and therefore is much harder to standardize across levels and domains of public administration. Computer science speaks of ontologies, which have to be developed in order to map the objects within dedicated domains (Staab and Studer 2004). Some national interoperability frameworks (NIFs) include basic semantic standards such as a government data catalog in the British eGIF. Another approach is core directories for e-government (Welzel et al. 2011). A directory is a structured collection of data, which may serve as point of entry (Welzel et al. 2011) or as a point of reference for validation of certain data. A core directory, according to Welzel, Hartenstein and von Lucke holds information on core elements of e-government, e.g., citizens, companies, public services etc. This concept is most
90
7 Layers of Interoperability
widely implemented in Belgium, where public agencies according to the “unique data collection principle” are not allowed to request information from citizens or businesses, which already have been collected by other pubic agencies. Rather for core data there are central registries, which serve as single authentic and reliable source for all public sector agencies (see E-Government Fact Sheet Belgium at http://www.epractice.eu/en/document/288179). A good example for the standardization of messages and for core directories is the crossroads bank and its social security services in Belgium. It serves as an information broker for the exchange of data between local public social welfare centers in all municipalities. In this service for inter-sectoral communication, hundreds of forms previously exchanged have been reduced to three message types: “submission”, “distribution”, and “answer”. Each message type is composed of two parts: the headers (in XML or flat format) contain all necessary information for correct routing: sender and addressee, type and kind of message, mandatory information to obtain authorization, answer management. The message in itself (in XML, EDIFACT or flat format) contains the personal data (related to a Social Security Identification Number contained in the headers). The communications between back-offices rely on XML-structured messages while the CBSS (CrossRoads Bank for Social Security) ensures protocol and syntax conversion, if necessary, as well as a validation service of identity data via a link to the central register of residents. The input from the outside (web portal, FTP, interbanking network) is collected through the Extranet and directly converted into structured messages. The connection between the CBSS and the social security institutions is made through the Extranet to which all social security institutions have a direct connection. In the road traffic accident automation project (case no. 8), semantic interoperability has been achieved by the standardization of the data-fields of the compensation forms by the hospitals, the translation of these forms for transfer between the two departments dealing with compensation, and the integration of the converted data (forms) into their respective legacy applications. In the company e-registration service of Sweden (case no. 5), applicants can apply for registration at the Swedish Company Registration Office (Bolagsverket) and the Swedish Tax Agency (Skatteverket) using the same web-service. Both agencies have agreed that the same code is applied for data entered into the webform and then forwarded to both agencies simultaneously. Another example is the electronic invoicing case of Denmark, where, as of 1 February 2005, all public institutions in Denmark were required only to accept invoices from suppliers in electronic format (see case no. 11). In this case, by definition an electronic invoice is a bill converted to a format directly readable by the public sector’s accounting systems. For this purpose, standardized workflows were introduced for all public entities on different government levels and companies. A specific XML workflow was designed, which is routed by a central electronic postal service. Routing of messages from the originator to the receiver requires an electronic postal address. Different identifiers can be used, i.e., the tax registration number or a Global Location Number within an Electronic Article Number (EAN), which allows for the unique and unambiguous identification of physical locations and legal entities.
7.2 Organizational Interoperability Re-defined
91
Transport of the e-invoices is based on an ebMS (ebXML Message Service), and enveloping mechanisms are built on SOAP. This means that the addressing information, mainly the EAN number, is part of the ebMS header. Thus, the introduction of the EAN location numbers for companies and public authorities and its integration in the ebMS header of the invoice provides for semantic interoperability. These identifiers also allow for the routing of invoices to the correct recipient and their integration in the respective legacy systems. In addition, a semantic validation tool checks as many integrity rules as possible providing the XML schemas with high integrity. Generally, XML schemas can go a long way regarding validation, but the technology cannot capture all rules of integrity that the legislation may contain. Thus XML schemas cannot replace the checking of integrity rules that a programmer can code. However, other schema languages like Schematron can go even further than XML schemas (for further information see: ISO/IEC FDIS 19757–3 – http://www.schematron.com/iso/dsdl-3-fdis.pdf), which has been deployed in the e-invoicing project. While standards for technical and syntactic interoperability provide for content independent data exchange, semantic interoperability is highly application-specific and thus depending on the service-specific content. As shown, to achieve semantic interoperability, agencies involved in a specific e-service commonly need to agree on the use of the same data exchange formats and codes for a particular service. This can be challenging when existing legacy systems in the cooperating back offices are using different data keys but need to be aligned to a common scheme. Such a change will only be undertaken when there is a trade-off between the cost of adapting the existing system and advantages to be gained from the shift to the common standards, or if the adoption of new standards is made mandatory by higher ranking agencies or legislation. Hence, achieving semantic interoperability is much more demanding than achieving technical and syntactic interoperability. However, 29 of 31 cases of specific services surveyed have achieved semantic interoperability.
7.2
Organizational Interoperability Re-defined
In Sect. 3.6 we proposed to separate what so far was called “organizational interoperability” into three dimensions. We argued that only technical standards for the linkage of business processes should be considered as additional layer above technical, syntactic and semantic interoperability, and we proposed to rename this layer “business process interoperability,” or BPI. Other aspects like change management, interoperability agreements etc. we maintained could be viewed as crosscutting aspects of how to achieve and maintain the different kinds of interoperability. These can be grouped into two different areas of governance, that is, IT governance and implementation of interoperability (Fig. 3.7). Business process interoperability purely focuses on the technical side of automated processing of sub-functions to one single (inter-organizational)
92
7 Layers of Interoperability
automated workflow. This may be achieved through common service architecture and securing interoperability on the three lower layers. A prominent example of how BPI can be achieved within a service is the use of a Service-Oriented-Architecture (SOA), which allows for the common description of inter-organizational processes, when business process definition languages are standardized, e.g., web services defined in WSDL (Web Services Definition Language) or BPML (Business Process Modeling Language). In the road traffic accident automation project the filing of the compensation forms by the hospitals was centrally secured as a web-service. The inter-organizational workflows with automated data integration between the two national departments were jointly agreed upon, modeled in SOA, and finally rolled out. Routing the forms to the receiving insurance companies was also done based on SOA. Another example is the certificate of residence service in Austria (see case no. 12). Quite a few institutions like social security administrations, schools, universities, or insurance companies require this type of certificate as proof of residence. The service can be fully provided electronically and automated as illustrated by the workflow diagram in Fig. 7.2. In order to apply for a certificate of residence, a citizen has to pass an identification and authentication procedure before filling in and signing an online application form. For this purpose the citizen has to allow the server application to extract the identity link from the e-signature card or from the server of a specific mobile phone provider (in case the citizen has an active contract with the provider). The browser then displays the form, which the citizen had used before, updated with additional personal information from the server. The citizen does not have to enter any personal information. The server module uses the identifier from the e-signature card to search the central register of residence (CRR) for the citizen’s personal information. In the next step the citizen signs the form using a personal e-signature card again (including the entering of a PIN) and submits it. By generating a hash value of the message and encrypting it with the sender’s private key the Austrian PKI specifies that the application form was signed. Alternatively to the e-signature card, authentication and digital signing can be provided by mobile phone. The procedure makes use of the fact that the mobile phone provider already identified the user when subscribing him to the network. Therefore a digital signature can be safely linked to a person’s identity. The workflow with the mobile phone function contains SMS service and requires the entering of PIN and TAN transmitted by the payment provider. After identification, authentication, digital signing, and form submitting, the certificate of residence service is immediately and automatically processed. Accessing the CRR and generating the certificate can be completed in a matter of seconds. Also, the payment procedure is fully integrated via a private payment provider. This provider asks the citizen for authorization of payment, which is given by sending a SMS containing a PIN. The payment application then sends a payment confirmation to the administration’s application, which automatically hands the certificate over to the delivery services of the citizen. Payment confirmations are standardized XML messages conforming to the Electronic Payment Standard (EPS2). Finally, the citizen receives a notification from
one stage
interface
authentication*
for application and user
Provides
Portal help.gv.at
certifi-
cate and delivers it
Generates
turns domain specific
authenticates user, (re-
Checks identity and
Register of Residence (CRR)
NATIONAL PUBLIC ADMINISTRATION
Fig. 7.2 Workflow of certificate of residence in Austria
Receives file, printout or letter
service and downloads certificate
Logs on to delivery
payment provider
User is redirected to
Sends online form
USER
Workflow of certificate of residence - Austria
residence data
Feed registry with
Local Registry Offices
LOCAL PUBLIC ADMINISTRATION
multi stage
notification,
service
ing or delivers by postal
that a document is wait-
Sends
Delivery Service (wdeliver.itsolution.at)
to BO
sends confirmation
phone, payment
hand
Enquires TAN via
Payment Provider (Paybox)
PRIVATE BUSINESSES
7.2 Organizational Interoperability Re-defined 93
94
7 Layers of Interoperability
the delivery service that a certificate is ready for downloading. The citizen has to pass through another authentication procedure either by e-signature card or via mobile phone. The downloadable document is an encrypted XML file, which can be downloaded to the citizen’s system, saved in a secure data box or printed on paper in legible form. If required by the agency, a delivery confirmation is automatically returned for receiving the certificate. Like semantic interoperability BPI is application or service-specific. It requires cooperation among the agencies involved in the particular service, or, if agencies are part of a specific domain within the public sector, the same challenges for governance. The above example of linking different workflows related to the certificate of residence service in Austria perfectly illustrates the application-specific dependencies to achieve semantic interoperability and, on top of that, BPI (Fig. 4.2). Obviously the integration of jointly used workflows is and remains complex, in general. Service oriented architectures including web services provide the basis for achieving BPI. Modeling languages like WSDL or BPML can facilitate standardized rules and framework conditions for the creation and linkage of backoffice workflows enabling automated service delivery. Moreover, further processes can be integrated more easily to extend service provision. Establishing BPI is the most mature achievement in automated online service provision. In our survey, 20 of 31 specific-service cases had advanced towards full BPI.
7.3
Cumulative Structure of Interoperability Layers
As mentioned in Chap. 3, IFs assume a kind of maturity hierarchy with regard to the four technology-related layers of interoperability. A higher layer allows for a higher degree of automation of a multi-unit workflow and the corresponding service. Following the construction principle of the OSI reference model (Fig. 2.1 and Table 2.1) one would assume that a higher level of interoperability can only be achieved if the subordinate layers are enacted. In other words, semantic interoperability can only be achieved when standards for syntactic and technical interoperability have successfully been implemented. Table 7.1 shows the number of good-practice cases in our sample, which achieved respective levels of interoperability: The figures support the assumption of a hierarchical or cumulative structure as the number of achievements of semantic interoperability is smaller than the number of cases achieving syntactic interoperability, and the number of cases reaching business process interoperability is even smaller. However, this is not a definitive proof because some cases may show BPI without providing semantic interoperability. Table 7.1 Distribution of interoperability layers achieved among 77 cases Layer of interoperability Technical Syntactic Semantic No. of cases 77 77 60
Business process 44
7.3 Cumulative Structure of Interoperability Layers
95
For testing the relationship between the four layers of interoperability, we borrow a method from scale construction in empirical social science. A cumulative structure exists if a number of items in a questionnaire is uni-dimensional and can be combined into an index in a way so that every respondent who agrees to a certain item also agrees to a number of other items. Scales of such a cumulative structure are called Guttman scales after Louis Guttman who developed the test method in the 1940s represented in so-called scalograms (Guttman 1950). In a ‘perfect’ Guttman scale all surveyed cases are characterized by the same cumulative structure of the items of a questionnaire. Therefore this structure can be reproduced in every case of a sample and hopefully beyond that sample. For a less perfect scale the pattern of responses can only be reproduced for a certain percentage of cases. The measure for the degree of perfection is expressed by the reproducibility coefficient with a range between 0 and 1. It is calculated by the formula: Reproducibility coefficient ¼ 1 – (number of errors/number of cases number of items) (cf. Kenny and Rubin 1977, or Grimm and Yarnold 1995). We apply this method to test for the existence of standards on different layers of interoperability in our good-practice cases. According to our hypothesis, whenever an interoperability standard is detected in a project on a higher layer of interoperability, also the interoperability standards on all lower layers will be found. We coded our cases accordingly (yes ¼ 1, no ¼ 0) and ordered the cases according to the number of standardized interoperability layers detected in decreasing order. We also calculated the reproducibility coefficient. The table in Annex 3 shows the complete listing of all 74 cases with the decreasing number of standardized interoperability layers involved in each case, starting with cases where standards from all four layers were found followed by cases with standards on the three lower layers etc. Table 7.2 shows the summary: Table 7.2 Cumulative structure of layers of interoperability Number of cases Technical Syntactic 40 1 1 20 1 1 13 1 1
Semantic 1 1 0
Business process 1 0 0
The table shows the verification of a cumulative structure for 73 out of 77 cases. The pattern of score with the Figure ‘1’ comes very close to a triangle. For this distribution a reproducibility coefficient of 0.97403 has been calculated. There are only four cases, which do not fit to the overall pattern: the Mobile Government Infrastructure of Malta (see case no. 13), Electronic Service Delivery Toolkit (UK) (see case no. 14), ELAK im Bund (AT) (see case no. 17), and Hamburg Gateway (DE) (see case no. 16). These four systems have achieved business process interoperability without providing semantic interoperability (Table 7.3). These four cases are not about providing a specific public service to citizens or business but deal with providing an infrastructure for an undefined number of services, which is something quite different. Infrastructures only provide some generic preconditions, which always have to be completed by service-specific
96 Table 7.3 Cases not fitting to the cumulative structure ID Name of case Technical Syntactic 31 Mobile government infrastructure 1 1 67 ESD – electronic service delivery 1 1 toolkit 89 ELAK im BUND 1 1 100 Hamburg Gateway – The digital 1 1 gate to the city
7 Layers of Interoperability
Semantic
Bus procs 1 1
Faults 2 2
1 1
2 2
elements, and most likely these have to do with the semantics of the respective service. If we ignore these four infrastructure-related cases, the four layers of interoperability as defined before form a perfect Guttman scale. Wherever a higher level of interoperability was achieved, we found all lower layers with standardized interoperability as well.
Chapter 8
Modes of Implementation of Interoperability
Interoperability frameworks (IFs) recommend or prescribe the adoption of certain standards for networks, data, or workflows in the development of IT applications. When presenting our basic ideas for a re-conceptualization of what so far has been labeled organizational interoperability we emphasized that direct data exchanges between organizations was observably the exception rather than the rule (Fig. 3.6). While standards and interfaces have been adopted, still involvement of intermediaries and outsourcing of certain supporting functions might be viable avenue when implementing standards for interoperability. We have called these units intermediaries, or clearing centers, leaning on the term used in electronic funds transfer and in the EDI-/EDIFACT context. With regard to the electronic ordering and invoicing between retailers and manufacturers of branded goods these clearing centers provide services such as repackaging and routing of messages, adoption and translation of different data exchange formats or versions of EDI standards or directory services. A good example of the economic benefit of employing such supportive services centrally is the administration of the European Article Number (EAN) in electronic ordering and invoicing. It is an absolute necessity to unambiguously identify goods ordered and billed. Several industry associations have issued the EAN as a product code. It is printed on almost all branded goods in the food industry and many other consumer goods. Because stakeholders were afraid of building a new bureaucracy, the EAN coding was designed as a completely decentralized system, assigning a single producer number to each producer and leaving it up to the producer to number his products (Kubicek and Seeger 1992). If a producer introduces new products or new ways of packaging, he has to notify all his customers who have to update their local EAN databases. In some countries, however, the associations of retailers and supermarkets considered it more efficient if the agency administering the producer number also maintains an up-to-date central EAN database, which can be accessed to update the local database of each retailer. Such a database can also be conceived as a core directory in the sense mentioned in the previous chapter in connection with the good-practice cases lomake.fi portal in Finland and the Crossroads Bank for Social Security (CBSS) in Belgium. H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_8, # Springer-Verlag Berlin Heidelberg 2011
97
98
8 Modes of Implementation of Interoperability
In a more abstract view we may conclude that when implementing interoperability standards, a certain degree of technical and organizational centralization is still necessary when agreed upon standards are not fully adopted by all participating units. From a governance point of view providing data format conversion services may be the price for introducing new standards because they allow sticking to old formats for some members of a community without them worrying about compliance. Before this background we may assume a complementary relation between adhering to agreed-upon standards and providing certain centralized support functions (Fig. 8.1). Full compliance with standards would eliminate the need for centralized support functions, while with decreasing degrees of compliance this need increases. Figure 8.1 shows how projects can be mapped along the two dimensions, the relationship of which can easily be subjected to empirical testing. However, this would also require a scale of support services, which are provided centrally in an e-government network. Unfortunately, so far these centrally provided auxiliary functions have not been classified. Therefore, it was one of the objectives of this study to develop an empirically grounded classification (i.e., a taxonomy) of the range of options when establishing and maintaining interoperation in government. In this chapter, we discuss a set of functional areas, which have been standardized in our good-practice cases, as well as a number of functions, which have been centralized. Then we check whether the respective items show a cumulative structure, and in the final section we look for patterns relating these measures to interoperability requirements, levels of governments, and other conditions.
Fig. 8.1 Complementary relation between standardization and centralization
8.1 Standardization for Interoperation
8.1
99
Standardization for Interoperation
The four technology-related layers of technical, syntactic, semantic, and business process interoperability are rather abstract and generic. In a separate analysis we identified more tangible components, which have been standardized. On the technical layer established telecommunication or Internet standards are always applied. With regard to the higher layers we have identified standardization efforts in our good-practice cases with regard to the following components: • Data exchange formats, i.e., format description languages, EDIFACT, XML, national standards such as OSCI in Germany, proprietary message types (syntactic interoperability); • Data keys, codes, and ontologies for data fields within formatted messages (semantic interoperability); • Workflow definitions according to common description languages (business process interoperability). In addition, we look at core directories providing key data for the identification of objects and in particular for providing address data for the routing of messages. These may be provided either in a centralized or decentralized fashion according to established standards like domain name servers on the Internet. Table 8.1 summarizes to which extent and how these issues have been standardized in the specific-service cases in our sample. The short description of the standardization efforts in these cases shows that the standardization of directories is less frequent than one might expect. It is obvious that in cases where messages are exchanged between different organizations, some kind of routing based on directories is necessary to find and determine the recipient. But this has not necessarily to be achieved by standardization of local directories. Rather, interoperation can also be attained by means of a central directory. Instead of each participating organization individually maintaining such a directory according to certain standards, it might be much more efficient to have one central provider who maintains and updates this directory. Indeed, in 62 out of 77 cases we find such central directory service and only in 17 cases a standardization of decentralized directories. Table 8.2 shows the frequencies of the four items for all cases and for the specific-service cases: As the standardization of data exchange formats, data keys and workflows corresponds to the layers of syntactic, semantic, and business process interoperability, and since these three layers form a cumulative structure, it is interesting to see whether or not such a structure can be identified for directories, too. The particular role of directories, however, has to be excluded from a scalogram analysis. For the standardization of the other three kinds of components we find an almost perfect Guttman scale as expected, especially if we only consider the single service cases.
No. 3: Data exchange Standardized directories serve the access of the format for civil (electronic) address data registration in of authorities (DVDV) Germany (X-Meld) and – based on this, enable routing of messages
OSCI-Transport and OSCI-XMeld are used for data exchange and are nationwide standards in Germany
Table 8.1 Examples of standardization efforts in good-practice cases Standardization in IOP Directories Data exchange format good-practice cases Secure data interchange No. 1: Application and Standardized directories are standard between Civil approval of child involved for the routing Registration and Child benefit in Ireland of data to the respective Benefit section is based on addressee in those cases the Inter Agency Messaging where IAMS and DISC Service standard (IAMS) are not involved, like from hospitals via local registrars to GRO No. 4: Social security Standardized directories in the Three commonly used message benefits in Belgium soc. sec. institutions enable types have been defined: accessing the various submission, distribution, services and answer in XML, EDIFACT or flat format Data exchange formats have No. 6: Central register No standardized directories been defined between the as only a central address of residence ZMR unit and the local directory exist in Austria registries and realized using XML interfaces Workflows
A main commonly used data Electronic workflows have key is the Social Security been enabled due to the Identification Number for intercession of the CBSS. identification and routing All applications use of messages services of the CBSS New workflows have been Standardized data keys have defined as the ZMR is now been defined to enable responsible for the service updating the CRR and to delivery. The local enable correct retrievals authorities had to integrate from the CRR. With the the CRR in their workflows ZMR number for each to e.g. update registry data citizen, a unique identifier or to enable updating of is used for linking and local directories by the CRR routing the applications Data keys of Civil Registration Whole workflows had to be adapted to enable electronic data in X-Meld messages flows such as secure have been standardized transport, access of DVDV throughout Germany registry and finally enabling automated change of address or, registration information service
The data set of e-birth Standardized internotification of the Civil organizational workflows Registration has been between the various actors standardized throughout the have been employed process based on the unique eliminating action by personal public service citizens in most cases number (PPSN)
Data keys
100 8 Modes of Implementation of Interoperability
No. 17: eInvoicing in Finland
No. 11: eInvoicing in Denmark
No central process control is With OIO-XML, Denmark The “OIO-XML electronic employed as OIO-XML standardized data exchange invoice” consists of a does not define workflows of in the whole public defined data set to be used particular services and is administration. The UBL by all actors for general not centrally controlled on and XML based standard invoices. The EAN location service level OIO-XML enables numbers is data key for standardized data exchange linkage and routing of applications Even though there are about Data keys of the e-invoices, Electronic workflows between No standardized address 15 e-invoicing operators in particular Finvoice the suppliers and public registers are employed. with different standards, and e-Invoice have been authorities have been Users send invoices to their there has been standardized. employed enabling e.g. e-invoicing operator. The a standardization approach automated conversion and operator then reworks and to align these standards and routing of the e-Invoices forwards the invoice to the public administrations are among the service providers addressee only allowed to use two particular standards each with a defined and standardized data exchange format each
No standardized address registers are employed as OIO-XML is a general standardization approach and not about a particular service
8.1 Standardization for Interoperation 101
102
8 Modes of Implementation of Interoperability
Table 8.2 Frequency of standardization items Standardization of All cases (77) Directories 17 Data exchange formats 70 Data keys and ontologies 56 Workflows 58
Specific-service cases (31) 9 31 27 26
In practical terms such a cumulative structure can be interpreted as a maturity model of standardization for interoperability in government allowing for an increasing degree of inter-organizational process integration and automation. On level 1 only the syntax of electronic messages is standardized. Messages cannot be automatically processed but rather need a human operator for checking the content and initiating further processing. There is no need for new data entry. On level 2 data keys or ontologies are standardized for some data elements. Therefore automatic recognition is possible, which allows for automatic processing if the respective workflows are coordinated – a step that requires additional efforts. In any case there is lesser need for human intervention than on level 1. On level 3 source and target workflows are defined and described in a standardized way. Thus not only automatic processing of messages becomes possible, but also the coordinated adaption and change of these workflows over time. Table III-2 in Annex III shows the coding of each case and illustrates the cumulative structure. In a perfect cumulative structure any project where workflows have been standardized there is also a standardization of data keys and data exchange formats and wherever data keys or ontologies have been standardized, there are standardized data exchange formats as well. For our 31 specific-service cases the reproducibility coefficient is 0.935. The cumulative structure is present in 28 cases out of which 23 have employed standards for all three kinds of components. Only three cases do not correspond to the cumulative structure. These cases have standard data exchange format and workflow descriptions but no standardized data keys (Table 8.3). Table 8.3 Cases with deviations from the cumulative structure No. Name of case Data ex-change Data format keys 18 My student fund (“My-SU”) 1 0 7 Bibliotek.dk 1 0 19 CFENet: Centre for company 1 0 formalities on the net
Work-flow de-finitions 1 1 1
Deviations 2 2 2
In a second analysis of these cases we find that no additional data keys have been standardized within the interoperability projects but rather already existing identifiers have been continued, i.e., name and enrollment number of students, author and title of books and company registration number. Insofar these cases also fit to the maturity model outlined above.
8.2 Centralization for Interoperation
8.2
103
Centralization for Interoperation
With regard to interoperation we assume that where standards are not adhered to completely or where separated maintenance of shared resources is more expensive, a centralization of certain functions is advantageous (Fig. 8.1). In our good-practice cases we have found the following central provisions: Three centralized services are related to directories. As mentioned before, it is often much more advantageous to keep and maintain directories centrally, which are to be used by multiple agencies and for multiple services. Altogether we found three kinds of directories, which were provided centrally: 1. Address directories for routing messages, which contain the addresses of receiving agencies; 2. Authentication directories for authentication at login, either service-specific or general, via certificates centrally provided by certification authorities (CAs) for national electronic identities or electronic signatures; 3. Core directories, which contain data key codes used in certain data fields of messages, e.g., for citizen or business master data, cars, real estate, etc. (see Welzel et al. 2011). In addition, two process-related functions are sometimes provided centrally: 4. The conversion of data formats, if sending and receiving agencies use different versions of the same exchange format; 5. Process control, such as format validation of messages, tracking and tracing. Table 8.4 shows the extent of centralization for the five functions in both the entire sample of cases and the sub-sample of specific-service cases. Table 8.4 Frequency of central provision of supportive functions Centralization of All cases (77)
Specific-service cases (31)
Address directory Authentication directory Core directories Conversion of data formats Process control
27 23 14 17 25
62 60 38 33 55
Looking at the specific-service cases, we found message routing via a central directory most common, followed by some kind of process control. Providing address authentication data centrally was the next most frequent. In 14 cases additional core directories were provided centrally. The conversion of data exchange formats, as mentioned, only became necessary if not all participants adhered to a common exchange format or did not use the same version. This included cases, in which the adoption did not pay off for some participants, e.g. because of sunk cost, when adapting existing legacy systems. Table 8.5 presents examples from our good-practice cases:
Table 8.5 Examples of central provision of supportive functions Centralization in Address directory Authentication directory Core directory IOP Good-practice case No core data are The GRO contains No. 1: Application Beside others, there is centrally stored. Each central provided data central routing from and approval of department stores and of the parents and the the Civil Registration child benefit in maintains its own children that is (GRO) via the broker Ireland data necessary for necessary to calculate in the Department for service provision benefits. This data can Social and Family be accessed by Affaires to the Child authorized agencies Benefit section using the PPSN No. 4: Social Routing and re-grouping The main element of the During the revision of Security of messages between CBSS is the central the soc. sec. sector Benefits in 2,000 offices by the ‘reference directory’ the legal division of Belgium ‘reference directory’ that contains mirrored authority between all of the central registration data of social security offices clearinghouse – the Belgian inhabitants, was respected, i.e., Crossroads Bank for and directories for they still maintain the Social Security authentication of data and the CBSS (CBSS) customers does not maintain any core data Access is centrally A limited set of mirrored Routing between the No. 6: Central provided via an civil registration data local registration register of authorization system (core data) is stored offices is centrally residence in that also enables the centrally. But provided via the Austria routing of messages authorities may also Central Register use the CRR as their of Residence (CRR) main resource for civil registration data Process control
No conversion as only a unique standard is used in CRR. For possible adaptation of local systems, interfaces are de-centrally required
The CRR provides validation and other quality control services
Generally, data exchange Process control is provided by the format is underlying public standardized. But in service broker model, some cases, data e.g., developing and formats need to be maintaining IAMS converted into the format of the receiving authority by IAMS and DISC The CBSS provides for The input from the centralised process outside (web portal, control like formal FTP, internet banking validation of network) is collected messages and also through the Extranet enables tracking and and directly converted tracing into structured (XML) messages
Conversion of data formats
104 8 Modes of Implementation of Interoperability
No. 3: Data No central routing takes Address data of In cases where the hub on No central process No core data are authorities at 15 hubs exchange place. Authorities ask state level is involved provided centrally. control is employed, (clearing houses) on format for civil for correct addresses conversion of the Authorities store and since no central stage state level are registration in at the centralized incoming data into the still are responsible exists. provided centrally Germany (XDVDV and send data format of the for maintenance of (DVDV). These serve Meld) messages directly to software of the data and service for authentication of receiving authority receiving registration provision on local authorities and or via the central hub office takes place via level provide for correct on state level specific libraries on routing of messages state level No 11: eInvoicing Routing of invoices Address data of all public No core data are The VANS network Within the VANS in Denmark between suppliers authorities in provided centrally. converts the incoming network, process and public authorities Denmark are shared Service data are still invoice into the control is provided is via the central by the central VANS hold and maintained standardized OIOe.g. in form of electronic postal network also serving de-centrally XML e-invoicing workflow and quality service providers for authentication of format and forwards control (VANS) using the users it to the recipient EAN location number (address directory) No authentication is No core data are stored The e-invoice operators Central process control No. 17: eInvoicing Invoices can be sent is provided by the provided on central centrally. E-invoicing in Finland throughout Finland convert incoming different e-invoicing level operators only invoices into the without needing to operators convert and forward format that is used in know the service messages to the provider and the the receiving addressee organisation and takes specific e-invoicing care on the routing. format of the No data is stored at addressee. Routing the operators is enabled by the different e-invoicing service providers that access a central address directory run by TIEKE
8.2 Centralization for Interoperation 105
106
8.3
8 Modes of Implementation of Interoperability
Relationship Between Standardization and Centralization
When introducing the standardization and centralization items, we had proposed the hypothesis that a central conversion of data formats is a substitute for missing compliance with standards (Fig. 8.1) The cross tabulation of the two respective items in Table 8.6 shows that standardization of data exchange formats was detected in all 31 specific-service cases, and in slightly more than 50% we also Table 8.6 Cross tabulation of centralization with standardization 31 specific-service cases Standardization Data Data keys of directories exchange n Centralization of address directory Authentication directory Core directory Process control Conversion of exchange formats
Workflows
9 5 (56%)
31 27 (87%)
27 23 (85%)
26 22 (85%)
n 27
6 (67%) 4 (44%) 8 (89%) 6 (67%)
23 (74%) 14 (45%) 25 (81%) 17 (55%)
21 (78%) 13 (48%) 21 (78%) 15 (56%)
19 (73%) 12 (46%) 21 (25%) 14 (54%)
23 14 25 17
found central conversion services (17 out of 31). We conclude that standardization and conversion are not mutually exclusive alternatives but rather central format conversion service is a political compensation for broad agreement to a certain standardization, allowing those members of a network the possibility to maintain their existing formats and having them converted into the new one. Interestingly, in 5 of 27 cases with central routing based on a central directory, we found standards for decentralized address directories, too. The same applies to directories for authentication and core directories for key data we still found centralization in 67% and 44% of the cases.
8.4
Summary
In this chapter we elaborated on the hypothesis that interoperability for crossagency public services depends on standardizing the various functional areas. However, standardization does not necessarily lead to interoperation in a network if compliance to standards is incomplete. In this case, centrally provided support functions can fill the gap of incomplete standardization. From a sample of 31 specific-service cases we constructed both a standardization scale and a centralization scale for assessing, which functional areas had been standardized, and which services were provided centrally. The standardization scale includes three items and forms a cumulative structure, which can be interpreted as a maturity model: In all cases data exchange formats were standardized (level 1). On the next higher
8.4 Summary
107
level (level 2), key data were standardized as well. Last, in the most advanced cases, also workflows were standardized (level 3) in order to allow for full automatic processing across agencies. The centralization scale includes the central provision of three kinds of directories, for routing, for authentication and for core data, as well as some kind of process control and for the conversion of data exchange formats. While directories for routing and authentication were found in the majority of cases, core directories were less frequent. With regard to the relation between the standardization of data exchange formats and central conversion service we found these services in 55% of the cases, corroborating our hypothesis that standardization might not necessarily lead to interoperation and that conversion services can compensate for missing readiness to adapt local systems and to implement these standards. With regard to the practical implications of our findings presented in this chapter we would like to emphasize once more that interoperability is not only a matter of defining and selecting standards and the respective model of governance, but it also requires an implementation strategy, which has not been sufficiently considered in the EIF and NIFs so far. This chapter sheds some light on this important issue.
.
Chapter 9
IT Governance of Collaboration for Interoperability
In this chapter we turn our attention to the choices of governance regimes for interoperated electronic government services on the national or regional level. As outlined in Chap. 2, the cooperating partners, for example, need to define the services, distribute the tasks, and share the cost. Also, the model of overall governance needs to be specified as well as the IT governance model regarding the definition or selection of technical standards, provision of central IT services, etc. The basic political decision regards the organizational choice between either (a) The provision of a new or improved service by organizational centralization and technical integration of previously decentralized and separated units and systems or (b) By forming a federation, which agrees on certain coordinated workflows and technical standards in order to provide the service in a one-stop-shopping fashion. The centralization option does not require interoperability between decentralized systems but rather system integration with shifts in authority and influence as well as new task and job assignments, which therefore frequently meets stiff resistance. As a consequence, the federation strategy is more often used but meets other challenges, in particular, the challenge of interoperability between the still separated components. This is the subject of IT-Governance. As outlined in Chap. 3, the four types of interoperability standards neither have and nor need a common governance structure. Technical and syntactic standards are developed and issued by international standardization committees or Internet working groups. National or regional government officials may participate in these bodies. However, when planning for a specific e-service the choices are made from a list the existing standards, open or proprietary, established or new. In contrast, for the semantic and business process layers, standards can immediately be designed to meet the needs of the specific service under consideration. Figure 9.1 illustrates these different options regarding standard selection and standard development.
H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_9, # Springer-Verlag Berlin Heidelberg 2011
109
110
9 IT Governance of Collaboration for Interoperability
Fig. 9.1 Interoperability governance with regard to different interoperability layers
While this pattern is quite similar for IT governance in both the private and the public sectors, these choices differ with regard to concrete structures and processes. IT Governance in industry primarily deals with structures of authority and hierarchical decision-making processes when setting standards within an enterprise. An enterprise may consist of several legally autonomous companies. The authority of a central Chief Information Officer (CIO) in this context may be limited, and the CIO may not succeed in implementing the exact same standards in all parts of the enterprise. But due to the structure of ownership a clear authority exits, which allows for enforcing the full implementation of strategically important processes and standards, for example, in the case of interlinking reservation systems after the merger of two or three airlines. In contrast, for public e-services, collaboration between public agencies from different sectors and levels of government is required. These agencies often have network relations, but no hierarchical relations. The agencies thus have to decide whether they want to participate, then negotiate their contribution, the modes of decision-making, and other details. We call this constellation of agencies, which is based on agreements leading to contracts or ordinances, a “federation” (see Sect. 2.3). In many cases the agencies, which have to build such a federation in order to cooperate in the provision of an e-service belong to different sectors and/or different levels of government, which might have never collaborated before. The great challenge for the governance of cross-agency public services and for
9 IT Governance of Collaboration for Interoperability
111
achieving the necessary interoperation arises from the lack of established vehicles for negotiating agreements, and frequently such vehicles have to be created. It seems that EIF and NIFs do not sufficiently recognize this complex constellation. Most of all they address the case of standard selection within an established regime of governance, but do not consider the cases where semantic issues have to be agreed upon by agencies without established modes of collaboration. This is not only a challenge for working together in the development of such standards but also for their implementation. In the comparison of national interoperability frameworks (IFs) we have seen federations producing either recommendations of standards or making them mandatory by directives with or without some kind of enforcement. In this section, we will discuss what modes of IT Governance and which patterns of intergovernmental collaboration for developing and implementing interoperability standards we find in our good-practice cases. The most interesting conclusion from a first analysis of these cases is that we were unable to identify one consistent governance structure for each project. Rather, the actor constellations change throughout the development process. This is in line with social science research on standardization, which suggests that a governance structure changes during the life cycle of standards. Most frequently found are three phases of a cyclical model: development, diffusion, and impact of standards. The development phase is characterized by different stakeholders and standard-setting bodies, which have different, and sometimes conflicting, interests in defining a standard. Besen and Farrell (1994) discussed the various strategies for business corporations when participating in the development of standards. Also, Schmidt and Werle (1998) described the negotiation mechanisms in standardsetting bodies with regard to telecommunications. The diffusion phase along with supporting and hindering factors for a widespread use of standards were explored in a number of fields ranging from telecommunications over video and TV formats to process standards. Damsgaard and Lyytinen (1998), e.g., pointed to institutional and technological barriers, which impede the diffusion of EDI standards. Corbett (2006) analyzed the global diffusion of a process standard for quality management (ISO 9000). The third phase, the impact of standards, is mainly subject to economic research. The core focus is on the effects on productivity (e.g. Tzelepis et al. 2006), international trade (Gandal and Shy 2001) or on macroeconomic growth (e.g. Blind and Jungmittag 2008). In this chapter we pursue a much narrower objective and refrain from trying to cover all these aspects of standard development and implementation within e-government including an analysis of its achievements and impacts. Before this could be done a heuristic approach might be required, which maps out the constellations of the standards planning and decision making authorities and how these constellations shifted over the course of the development process. Borrowing from more general models of lifecycles of standard quoted above we distinguish: • A planning phase of defining or selecting appropriate standards, • An authorization phase of standards, and • An operation and maintenance phase.
112
9 IT Governance of Collaboration for Interoperability
For each phase we found various institutional configurations for cooperation and coordination and also different degrees of participation or representation of stakeholders.
9.1
The Planning Phase
In the planning phase we found the working groups and ad hoc committees mentioned by Scholl and Klischewski (2007) as well as staff units, mainly composed of experts from the agencies in the respective administrative fields and/or ICT specialists. The organizational forms in this phase can be distinguished by their degree of institutionalization and representation.
9.1.1
Institutional Settings
On the business process and semantic layers, interoperability standards are elaborated in either existing or newly created institutions, which either have a permanent character or are established for a particular interoperability project for a certain time span. Consequently, the planning for the institutional setting can choose among four options (see Table 9.1): • Existing institutions cooperate in order to plan for an e-government project requiring interoperability. Frequently the lead institutions operate and maintain the e-service after the initial project is closed out. • A new permanent institution is created for planning a new service or the online channel of an existing service. Usually this new institution maintains and operates the service afterwards. • An existing working group of representatives from various institutions plans for service and interoperability. Characteristic for this type of operation is that previously existing inter-organizational cooperation also contributes toward the conceptualization of the new project. After successful project implementation the maintenance and operation is transferred to another institution. • A new temporary working group carries out the planning. This kind of group dissolves after the successful implementation of the project, and the maintenance and operation is transferred to another institution. Permanent existing institutions planned the majority (23) of the 31 specificservice cases. Few chose the option of assigning an existing temporary institution (2) or creating a new one (5). A new permanent institution was created in only one case. The case of the e-enabled child benefit service in Ireland (case no. 1, see also Fig. 1.3) is an example for planning performed by existing permanent institutions. This service was developed in cooperation between the national Department for
9.1 The Planning Phase
113
Social and Family Affairs (DSFA) and the General Register Office (GRO), as well as Reach, a cross-departmental agency established by the Irish government. Table 9.1 Institutional settings for the planning phase Existing institution Permanent National Ministries in the e-enabled child benefit service in Ireland Temporary (ad The working group EDIAKT II in hoc group) the standardized e-form exchange project in Austria
New institution Crossroads bank for social security in Belgium The OIO data standardization committee in OIO-XML project in Denmark
In inter-departmental meetings, the concept of a new way of new service delivery was discussed and agreed upon: • On the side of the DSFA, the Service Delivery Modernization Project was started specifically to introduce new technology, to redesign business processes, and to reform legislation, e.g., in order to forward birth notifications from the local registrar to the central civil registration service. • A major modernization initiative was already underway in the Irish civil registration service, in the form of the Civil Registration Modernization Program. This included digitization of records and computerization of the registration process and certificate production. • Reach developed the Inter Agency Messaging Service (IAMS), which provides the channel for data exchange such as electronic notification of birth, death, and marriage registrations between agencies. The only example of setting up a new permanent institution for planning a new service including interoperability is the Crossroads Bank for Social Security in Belgium, which has been mentioned several times (case no. 4). This institution was created as part of an initiative by political leaders to modernize the information flows within the social security system in Belgium. In 1986 The National Ministry for Social Affairs published a global plan for the computerization of social security and established a small working group with the mission to work out a plan for improving the information flows between the many agencies involved. The social security system in Belgian is characterized by five independent authority levels and three insurance systems (employees, self-employed workers, and civil servants) covering up to seven social risks (incapacity for work, industrial accident, occupational disease, unemployment, retirement, child care, and holiday pay). Funding of benefits in the social security domain is a duty of the Federal State; however, the service implementation is provided on the regional or local level. Altogether, about 2,000 offices on five government levels are concerned with social services. The working group was composed of members from the social security sector and from central federal IT services. The group did not propose structural changes of the whole system but rather a new autonomous public office, which was to reorganize the information flows between the existing agencies and serves as a kind
114
9 IT Governance of Collaboration for Interoperability
of clearing center or information broker. In 1991, the Crossroads Bank for Social Security (CBSS) had been established under national law. This office, together with the National Office for Social Security (NOSS) analyzed information flows, and designed new processes and message types with political support of the minister of Social Affairs and the minister for the Modernization of the Public Sector, who whenever necessary took care of legal backup. The CBSS is an excellent example for the successful linkage of political governance and IT governance. An example for IT governance in the context of a pre-existing group of representatives from existing institutions is the case of the working group EDIAKT II in the standardized e-form exchange project in Austria (see case no. 20). EDIAKT II is an XML schema, which describes electronic files, including their internal structure and general attributes. EDIAKT II facilitates the exchange of electronic files, business cases, and business processes among all Austrian office information systems (KIS) and electronic files systems (ELAK), and is intended to become the standard for long-term archiving. Generally, coordination of developments for an Austria-wide communication architecture takes place on a central level in the Federal Chancellery, in particular, through its ICT-board. Several working groups consisting of members from the federal, state, and municipal level, but also with partners from the business sector (when and where required) were formed for addressing various key issues. We found an uneven distribution of institutional approaches for governance in the planning phase in the 31 specific-service cases. In 49 of 77 cases (64%) and in 23 of 31 specific-service cases (74%) planning was assigned to or initiated by an existing permanent institution (see Table 9.2). Existing temporary working groups were found in 12%, respectively 6%. As mentioned above new permanent institutions were detected in only one of 31 specific-service cases but also in three other cases, in which infrastructure components had been introduced. As infrastructures for interoperability in government go beyond individual sectors it appears to make sense to establish new institutions for such new tasks. Table 9.2 Institutional configurations in the planning phase Existing institution New institution All cases Specific- service cases All cases Specific- service cases Permanent institution 49 (64%) 23 (74%) 4 (5%) 1 (3%) Temporary (ad hoc group) 9 (12%) 2 (6% ) 15 (19%) 5 (16%)
This overall preference for assigning planning for interoperability to existing institutions is in line with the theories of actor-centered institutionalism in social and political science, which assume a high degree of path dependency for innovations. In other words, actors show a preference for existing institutional paths in order to avoid additional resistance when planning for innovations. It might be often easier to convince people in an existing organization to take on new tasks than to organize political consent and acquire the resources to establish a new organization. Apparently new organizations are created if an organizational gap is found when planning for an inter-organizational data exchange,
9.1 The Planning Phase
115
i.e., if agencies with no history of exchange or coordination have to interoperate, or if political leaders do not trust existing organizations. Another reason for the dominance of existing institutions in interoperability planning is that initiatives for improving interoperability often come from existing organizations looking for additional tasks in order to corroborate their existence or growth. In most of these 23 cases the planning was done by the same organizations that chose or were designated to operate and maintain the respective standards later on. The assignment of interoperability planning to a temporary institution seemingly makes more sense in situations where it is not yet clear who might operate and maintain the standards later on. In these cases temporary institutions were often established for the planning phase. Cross tabulation of these different configurations for the planning for interoperability by requirements and layers of interoperability show only small differences. The level of government, in contrast, makes a difference. At the national level, permanent existing institutions were found most frequently. In 70% of the 77 cases in total and in 80% of the specific-services sub-sample planning for interoperability was assigned to an existing permanent institution. At the regional level we found temporary institutions employed more frequently for that purpose. When only a few regions work together on planning for interoperability this task in three of four cases was assigned to an existing institution and in only one case to a new temporary institution (Table 9.3). This tendency toward temporary institutions was even stronger for the specific-service cases, where this organizational format was used in all cases. Table 9.3 Cross tabulation institutional settings with level of government and service (77 cases) All 77 cases National Multi-regional Regional Multi-local Local Permanent existing 32 (70%) 0 11 (73%) 2 (40%) 4 (57%) 49 Permanent new 3 (7%) 0 0 1 (20%) 0 4 Temporary existing 2 (4%) 3 (75%) 1 (7%) 0 3 (43%) 9 Temporary new 9 (20%) 1 (25%) 3 (20%) 2 (40%) 0 15 n 46 4 15 5 () 7
To summarize, for the planning phase of interoperability projects we could identify four different forms of IT governance. The planning tasks were assigned to either existing or new permanent or temporary institutions. Planning by existing institutions was most frequently discovered in projects on national levels of government and in multi-service cases, which often were to integrate existing services, for which some kind of cooperation between the agencies involved had been established before. When only a few regions planned for interoperability as a completely new endeavor, new but only temporary institutions, i.e., project groups were set up. The creation of new permanent institutions was an exception and was found in only one of 31 cases.
116
9.1.2
9 IT Governance of Collaboration for Interoperability
Representation of Agencies Concerned
When several agencies were involved in providing an e-service to citizens and businesses, and when these agencies had to change work flows and ICT systems, it could be assumed that all those partners would have taken part in the planning for interoperability. “All partners” would not necessarily mean that each single agency was involved in all phases and details of the planning phase. In any case, the authority that supervised the agencies immediately involved had to have a say in establishing new rules. But it was not always the case that all partners were involved in the planning for interoperability. A common practice was to start with selected pilot applications in a smaller environment and then test a new system under real operating conditions before it was fully rolled out to all agencies concerned. Moreover, we also found cases, in which none of the other participating agencies were engaged in the planning phase, and the initializing authority performed the planning sometimes with help from external consultants. When speaking of representation in this context we mean the extent to which agencies from different branches or levels of government were represented in the institutional settings for the planning phase. In our good-practice cases, we found three options (Table 9.4): • No representation at all; • The representation of selected agencies participating in a pilot phase; or • The representation of all agencies concerned. Table 9.4 Different degrees of representation of agencies in the planning phase Representation No participation of Participation of selected All agencies concerned degree agencies concerned pilot agencies are represented Example Electronic tendering service Online declaration to e-enabled child benefit of Leeds, UK ( LETS) the police in Finland service in Ireland
A good example of the participation of all partners concerned in the service provision was found in the case of the e-enabled child benefit service in Ireland (see case no. 1). In this service, those authorities affecting the service provision were involved in the conceptualization phase. Several separate and linked back-offices were also involved in the process of enabling the proactive child benefit service. All these stakeholders were invited to take part in the planning, in detail, • The hospitals, in which the births took place. Hospitals were chartered with directly notifying the local registration offices of the births. By May of 2005, 17 maternity hospitals in Ireland were listed, five of which had an on-site registrar. • The Local Registrars’ Offices took care of the immediate registration. All 53 registration offices in Ireland were connected to the online system. • The General Register Office (GRO) chartered with registering vital events. The GRO, as well as the local Registrar’s Offices, were in charge of the civil registration service and belonged to the Department of Health and Children.
9.1 The Planning Phase
117
• The Central Records System (CRS) at the Department of Social and Family Affairs (DSFA), where a Personal Public Service Number (PPSN) and a Public Service Identity had to be created. • The Central Statistics Office where vital records were maintained, and • The Child Benefit Section of the Department of Social and Family Affairs (DSFA), where the child benefit claim had to be created. To be clear, not every hospital and agency took part in the conceptualization of the interoperability effort, but rather the respective supervisory authorities participated in the planning like the Department of Health in charge of the (state) hospitals or the GRO for the local registrars. Certainly, as local IT systems and practices had to be considered, some hospitals and agencies were also present. Moreover, the rollout of service did not cover all hospitals from the beginning. Rather, it was started with hospitals that reported most on-site births. A typical example for the participation of selected partners engaged in service provision is the online declaration to the police in Finland (see case no. 22). The case is based on two different trials, which were selected under the systematic evaluation of potential services during the web-service strategy work started in Finland in 2001. The political program of the government, which demanded an evaluation of the possibilities of developing adequate web services for citizens, provided the foundation for this strategic undertaking. Before this new standardized online service became available, all police districts had operated their own individual Internet services and developed their own systems. The Finnish strategy included the idea of a step-by-step development. The first step was a pilot application for use in two police districts. The final solution was based on the results of these pilots and was then disseminated to the remaining police departments as the next step. Finally, all police districts used the same system, which soon became part of the daily work for the police officers. An example, in which no partners were represented in the planning for interoperability, is the electronic tendering service of Leeds (UK) called LETS (case no. 23). The Leeds City Council developed this system in cooperation with the State Government of Western Australia. It enabled electronic tendering functions to buyers and suppliers as an extension of the existing tendering process. The City Council was the only provider of this service, and thus the main actor. LETS was designed as a Web-based open system, and anyone with an email address and access to the Internet could use the system. Any software required to read the tender documents posted on the site was to be available free of charge by following the hyperlinks included on the LETS system. Bids submitted electronically (as attachments) to the platform could be of any format, as LETS provided functionalities on the technical and syntactic layer to enable data exchange without requiring specific interfaces for data integration. Thus, involvement of other participants, in this case the bidders, was not considered necessary as it had not occurred before in the paper based process. In case data and workflow integration between bidders and the City Council was targeted, the involvement of those other parties would have been necessary.
118
9 IT Governance of Collaboration for Interoperability
As expected, in 39 of 77 surveyed cases (51%) and 20 of 31 specific-service cases (65%) all agencies involved in the (new) service provision were represented in the planning phase. But starting with selected pilot agencies was also very common. These were represented in 10 specific-service cases (32%). Planning without any representation was the exception in our sample and was discovered in only one specific-service case and four cases overall. The whole sample includes the development of infrastructure components and portals, where it was not certain in the beginning, which agencies would employ the new components or join the portal in the end. In these cases one authority took the lead in a hierarchically organized environment and planned for providing the service to others based on standard Internet technology. Such a hierarchical governance structure was found in the four cases with no representation: • • • •
HELP.gv.at Virtual Guide to Austrian Authorities (case no. 24) LETS Leeds Electronic Tendering System (case no. 23) ELAK im Bund (case no. 15) eID in Estonia (case no. 25).
9.2
Legitimacy and Authorization of Standards
In most cases, when working groups proposed standardized workflows and data exchange formats, certain authorizing bodies had to adopt, issue, recommend, or mandate those proposals. Legitimacy was attained by law or ordinance, by contract or agreement, or by the decision of an authorized and recognized board. When mapping compliance (mandatory or recommended standards) against the legal format (law/ordinance vs. contract/agreement), we were able to distinguish four different cases for providing legitimacy and for authorizing standards: • Standards are adopted by law, ordinance, or board decision and made mandatory. No other standards are allowed. This type of legitimization is the strongest and generally requires legislation. • Standards are made mandatory by agreement or contract. Signatories commit themselves to using only these standards. • Standards are recommended by law or ordinance, and their use is voluntary. • Standards are recommended by agreement or contract and, hence, their use is voluntary. Partners agree on certain standards but are not bound to actually use them. The changing priorities of partners are a potential risk to standard implementation, which makes them the weakest type of legitimization. Table 9.5 gives some examples of these different modes. A prominent example for standards adopted by law is the X-Meld standard in Germany’s civil registration service (see case no. 3). Civil registration in Germany is characterized by its federal structure. Federal law requires German citizens to register in a civil registry. Federal law also provides guidelines
9.2 Legitimacy and Authorization of Standards Table 9.5 Legitimacy and authorization of standards Mandatory (obligation) Law, ordinance X-Meld standard in civil registration service in Germany Agreement, contract RTA2 forms in the Road Traffic Accident project in UK
119
Voluntary (recommendation) Social security services in Belgium operated by the CBSS OIO-XML standards in Denmark
(“Melderechtsrahmengesetz”) for State legislation and local administrations, which operate the registries. The federal guidelines detail, which personal data have to be registered and who has access to the registries. The guidelines, however, do not prescribe workflows nor data exchange formats. The technical implementation of the guidelines lies in the autonomy of each municipality. As mentioned before, citizens who relocate are obliged to register in their new home municipality and deregister in their old one. To reduce administrative burden and maintain clean population data on municipal level, the State ministries responsible for civil registration agreed to require citizens only to register in their new home municipality, while this registration office would take care of the citizen’s deregistration with the former home municipality. However, in order to make this innovation happen the heterogeneous ICT systems in the municipalities had to be made interoperable. Neither a centralization of the local registries like in Austria, nor a harmonization of local systems was a political option. Instead the ministries agreed on a specific data exchange format, X-Meld, as mentioned before. When experts from several Federal States developed the standard, it was unclear how to implement it. Until that point in time, standards for e-Government only pertained to federal agencies but not to municipalities. However, electronic deregistration could only yield cost savings once all municipalities employed the same standard exchange format. If only a few municipalities insisted on maintaining a paper- based exchange, all the other agencies would have been forced to maintain two parallel processes, the old (paper-based) process and the new one. To avoid this pitfall, the State ministries agreed to make adopting X-Meld mandatory by a special legal order, the Civil Registration Data Transmission Directive. This was considered a heavy intervention of Federal and State legislators into the autonomy of local municipalities. Finally, the intervention was accepted since IT management units in civil registration had a long tradition of successful cooperation between the Federal States, in particular with regard to granting police departments access to local registries for authentication and identification purposes. An example for a standard just recommended by law is the social security services in Belgium operated by the Cross Roads Bank for Social Security (CBSS). As mentioned before CBSS was established as a clearing center or information broker by a special law and was assigned the task to reorganize and standardize the data exchange between the main agencies in the social security system. Standards and workflows were defined based on the Belgian interoperability framework, and European Directives were converted into national law, but no binding obligation was put forth for the agencies in the sector to be linked to the CBSS. From the
120
9 IT Governance of Collaboration for Interoperability
beginning, management of the CBSS worked to convince the social security institutions to take part in the new service provision. This was successful because institutions not integrated with the CBSS did not work efficiently. Thus, most social security institutions and other contributing organizations like national departments for finance or taxes, trade unions, employers, etc. were directly connected with CBSS. Although no legal obligation required the use CBSS services, CBSS data exchange formats and workflows soon became de-facto standards. An example for standards adopted by agreement is the use of XML and web services for the filing and transfer of RTA2 forms in the Road Traffic Accident project in the United Kingdom (case no. 8). A British Government directive required to e-enable public services by 2005. Every public department had to work towards this goal. The e-enabling of RTA2 forms was identified as a service suitable for digitization and, moreover, promising cost savings. The Department for Work and Pensions and the Department of Health, the main actors in the service delivery had to cooperate for the realization of the new service provision. They came to an agreement on the service transformation, but no law prescribed the agreed-upon reorganization. The new standards and processes were instituted, and exchange of RTA2 forms from then on required the new system. Beneficial to this service transformation, however, was the fact that the departments already had good relationships with one another. For example, for the sub-process of transferring the forms from the DoH to the DWP, they had agreed on the use of EDIFACT long before. The new service was the next step, migrating the EDIFACT system to an XML-based system, accompanied by digitization of the other sub-processes to create an electronic workflow from start to end. The OIO-XML schemes used in Denmark for communication within and with the public administration (case no. 21) is an example for standards recommended by agreement or contract. The project did not succeed in making the standards mandatory by law. Instead, the project team followed a bottom-up approach to implementation, arguing that users should employ the standards voluntarily based on their usefulness. This process required massive efforts convincing administrations and the private sector to use the standards. A prerequisite for the acceptance of the standards was making their benefits visible. This was not an easy task to complete since the standardization process included all levels of data models and was not only based on XML schemes. The conceptual, logical, and physical levels were visualized in order to communicate the benefits to decision makers without a technical background and motivate them to adopt the new data standards in their local systems. The distribution of the 31 specific-service good-practice cases regarding legitimacy and authorization was as follows (see Table 9.6): In over half of the 31 specific-service cases as well as for the total 77 cases standards were only recommended and not made mandatory. More than two thirds of the mandatory standards (71% and 66%) were authorized by legislation, while three quarters of the voluntary standards (71% and 73%) were issued by contracts or agreements.
9.2 Legitimacy and Authorization of Standards Table 9.6 Legitimacy and authorization of standards Mandatory standards (obligation to adopt) Sample Specific-service All cases cases (n ¼ 31) (n ¼ 77) Law, ordinance 10 (71%) 24 (66%) Agreement, 4 (29%) 12 (33%) contract n 14 36
121
Voluntary standards (recommendation to adopt) Specific-service All cases cases (n ¼ 31) (n ¼ 77) 5 (29%) 11 (27%) 12 (71%) 30 (73%) 17
41
In some cases it might not have been possible to reach political consensus on legislation obligating all involved agencies to adopt the respective standards, but choosing a softer strategy might also have had other reasons. From a rational point of view, the strategic choice may predominantly depend on the necessity of full adoption of a standard so that the objectives laid out for the new system could be achieved. In the case of the German X-Meld system, the standard for messages of registering and deregistering relocating citizens between several hundred local registries, voluntary adoption would have meant that each office had to operate two different processes in parallel. Beside the risk of a higher degree of errors, this would have been quite expensive. In this case of reciprocal interdependence, the savings of each single agency depended on the degree of adoption of the standards by all other agencies. In other cases without similar network effects, the argument for making a standard obligatory might not come across as strongly, for example, in case of prohibitive switching cost. In some cases in our sample, a deliberate choice had been made to start with recommendations rather than requirements regarding new systems. The Danish national standardization project OIO-XML maintained that convincing government agencies to use a certain standard by explaining the benefits of its use leads would lead to a more successful adoption rather than making the standard mandatory. In this line of argument, partners would ultimately be more satisfied with solutions that were implemented based on own choosing. However, given the distribution of powers between the different ministries in the Danish government mandating such a standard was not an option. In contrast the Belgian CBSS case shows that a voluntary strategy might result in de-facto mandatory standards over time: If a critical mass of agencies uses a certain standard, others are forced to use these standards to avoid the risk of being excluded from the community or of forfeiting connectivity. It is interesting, however, that also in cases, in which several agencies start a joint venture for interoperability, finally reach an agreement, and close a contract adoption of standards might still not be certain. Since this was not the exception but rather the rule in 71% of the specific-service cases and 73% of all cases, this finding calls for further analysis. A cross tabulation of the regime of compliance with the type of interoperability requirement shows that interoperability in almost half of the multi-service cases and two thirds of the multi-file cases was based on standard recommendations specified
122
9 IT Governance of Collaboration for Interoperability
in agreement for voluntary adoption (see Table 9.7). In contrast, in multi-area cases interoperability was most frequently established by mandatory standards laid down in laws or ordinances. The equality principle requires that public service has to be delivered in the same way to all entitled or addressed citizens in the same way, even if it is provided by different agencies in different regions. Table 9.7 Cross tabulation authorization of standards with interoperability requirements 31 specific-service cases Multi-service Multi-stages Multi-area Multi-files Mandatory by law or ordinance 1 (14%) 7 (30%) 2 (67%) 1 (33%) 10 Voluntary by law or ordinance 1 (14%) 5 (22%) 0 0 5 Mandatory by agreement or contract 2 (29%) 2 (9%) 1 (33%) 0 4 Voluntary by agreement or contract 3 (43%) 9 (39%) 0 2 (67%) 12 n 7 23 3 3 n
One might have expected it to be easier making standards mandatory on the semantic and business layers than the technical and syntactic layers since the former were most often developed by public agencies with a certain degree of participation. However, our cross tabulation of the different compliance modes with the four layers of interoperability showed almost no variance. We found, however, a systematic pattern with regard to the level of government: Almost two thirds of the standards for nationwide interoperability projects were established by law or ordinance (46% mandatory, 15% optional), while on the regional level contracts or agreements were most frequent (see Table 9.8). In almost all cases, local agencies reached agreements or closed contracts without a definitive obligation. This might be owed to the uncertainty regarding how much effort would have been required to implement the standards or integrate the new components into the existing ICT systems. Table 9.8 Cross tabulation authorization of standards and levels of government and service All 77 cases National Multi-regional Regional Multi-local Local Mandatory by law or ordinance Voluntary by law or ordinance Mandatory by agreement or contract Voluntary by agreement or contract n
9.3
21 (46% )
1 (25%)
2 (13%)
0
0
24
7 (15%)
0
4 (27%)
0
0
11
6 (13%)
3 (75%)
1 (7%)
0
2 (29%)
12
12 (26%)
0
8 (53%)
5 (100%)
5 (71%)
30
46
4
5
7
15
n
Operation and Maintenance of Standards
In a third phase, standards that were recommended or made mandatory still had to be implemented and put into operation by assigning certain tasks to certain organizations or units. In Chap. 8, we discussed which tasks were centralized. Here
9.3 Operation and Maintenance of Standards
123
we wanted to find out from an IT governance perspective what type of organization was assigned to which tasks. Those types of organizations could have been public, private, or organized in public-private partnerships. In many cases, control or supervision of the implementation was assigned to boards or committees, in particular for the promotion, diffusion, maintenance, and updates of the respective standards. Tasks of operation were more frequently assigned to governmental agencies, joint ventures, or private enterprises than service providers. We distinguish between maintenance of standards, i.e., design and documentation of updates, and operation, i.e., providing IT services, in particular, clearing and conversion services. Table 9.9 provides respective case examples. Table 9.9 Organization of maintenance and operation of standards Public Private PPP Maintenance OSCI control center on The Danish Bibliographic e-invoice behalf of KoopA ADV Centre in the Bibliotek. consortium for Civil Registration dk project in Finland project in Germany (X-Meld) Operation The German federal states in e-invoice service providers eID card service the X-Meld project in Finland consortium in Estonia
An example for public providers maintaining standards is the OSCI control center, which was established by the Koop ADV for the standardization of data exchange across levels of government in Germany, and specified X-Meld as the first message type for civil registration. KoopA ADV was a cooperation committee consisting of the federal administration, the states, and the local government central associations. This body defined and coordinated the principles for the use of information and communication technologies and large IT projects in public administration. Hence, in this nationwide project, representatives of all government levels were commonly involved. Detailed specifications for updates and documentation, however, could not be provided by such a committee. Rather, the members agreed to set up a permanent staff in the City State of Bremen to maintain the OSCI standard, while the operation, i.e., routing and conversion, was to be done by each state. Another example is the central finder for public services at all levels of government in Austria, help.gv.at. (HELP) (see case no. 24). HELP cooperated with the federal states in the Joint Federal and State level Working Group. The prototype of HELP was developed by a small team consisting of staff members of the IT Division of the Federal Ministry of Finance (BMF) and the private company “net-value”. On May 1, 2003, responsibility for the contents of help.gv.at was assigned to the Federal Chancellery (BKA); thus the Administrative Development Division of the Ministry was then entrusted with the maintenance and operation of HELP. Examples of private providers that maintain interoperability standards can be found in the case of the Danish library system bibliotek.de (see case no. 7). Although the Danish National Library Authority was in charge of bibliotek.dk and the system was financed by the Danish government, the standards were
124
9 IT Governance of Collaboration for Interoperability
maintained and operated privately. More particularly, the Danish Bibliographic Centre – which was a private company that formerly adhered to the public sector – developed bibliotek.dk and was paid a fixed price by the Danish National Library Authority. On top, the agency was paid an annual fee for the maintenance and operation of the system. Another example is the online crime declaration service in Finland. A central part of the service provision in technical terms was the lomake.fi portal (see case no. 10). Elma Ltd, a private company, was also responsible for the scalability of the system and maintained lomake.fi portal. Based on the number of electronic crime reports the Police paid the company. A prominent example of a public-private-partnership (PPP) that maintains interoperability standards is the e-invoice consortium in Finland (see case no. 17). TIEKE represented all public and private stakeholders and was an independent non-profit organization that established the e-invoice Forum that provided the infrastructure. Maintenance of interoperability standards and other components in most cases was kept within the public sector, and in only two cases of specific services it was completely outsourced to private sector entities (Table 9.10). In contrast, operation of standards including directory services, data format conversion, etc. was much more frequently enacted through private service providers or public-private partnerships, 16% each for specific services. In the whole sample including infrastructure components and portals we found PPPs even in one third of the cases (36%). Table 9.10 Cross tabulation Maintenance of Standards with Levels of Government All 77 cases National Multi-regional Regional Multi-local Local Maintenance by 38 (83%) 2 (50%) 14 (93%) 3 (60%) 5 (71%) public agencies Private agencies 2 (4%) 1 (25%) 0 0 0 PPP 6 (13%) 1 (25%) 1 (7%) 2 (40%) 2 (29%) n 46 4 15 5 7
62 3 12
The cross tabulation of organization type with interoperability requirements or layers of interoperability did not reveal any differences. With regard to the level of government we found private organizations in PPP most frequently in multiregional projects, i.e., when only a few regions collaborated to provide a public service (Table 9.10). With regard to the operation of standards, infrastructure components, and portals we found PPTs even more frequently on regional and local levels (see Table 9.11). Table 9.11 Cross tabulation operation of standards with levels of government All 77 cases National Multi-regional Regional Multilocal Maintenance by 27 (59%) 2 (50%) 9 (60%) 1 (20%) public agencies Private agencies 5 (11%) 0 1 (7%) 1 (20%) PPP 14 (30%) 2 (50%) 5 (33%) 3 (60%) n 46 4 15 5
Local 2 (29%)
41
1 (14%) 4 (57%) 7
8 28 n
9.3 Operation and Maintenance of Standards
125
In summary, by looking at three phases of the process of standard development, authorization and implementation we could identify different configurations for IT governance of interoperability. With regard to the government structure for the development of standards and other components for achieving interoperability, planning was either assigned to existing or new permanent or temporary institutions. When traditional public services were put online it was most likely that planning for interoperability was assigned to existing permanent institutions. If interoperability was required between systems of agencies, which until then had no cooperative relationship, planning by temporary working groups was found more frequently. Once standards were developed, a compliance regime had to be established. Standards might have been issued as mandatory or optional either by legislative action (law, ordinance, directive) or by contract or formal agreements. We found obligatory standards issued by legal measures most frequently for multi-area projects, through which the same service was provided by different agencies in different regions. A surprise finding was that in cases, in which regional agencies collaboratively worked on shared standards and reached a formal agreement, those partners would still not commit themselves to full compliance of the standards but only agree on recommendations. With regard to the implementation of standards we looked at the ownership of the agencies, which maintained and updated standards or provided of certain supportive functions or services. While maintenance most frequently was kept within the public sector, quite often support services were operated in publicprivate partnerships. We were not able to explain, under which conditions and for what reasons these different options had been chosen. This will be the task for future research. However, by describing in detail the various patterns and characteristics of interoperability projects we advanced the understanding of both IT governance in government and governance of interoperability, which were prominent but incomplete in the EIF and NIFs.
.
Chapter 10
Strategic Choices for Setting Up Interoperable E-Government Services
When e-government services are planned and interoperability requirements arise, IFs shall provide guidance about how to proceed and what options are available. Many NIFs provide information about standards to be applied, as well as potential building blocks for services. To a lesser degree they deal with IT governance options, and if they do, NIFs are confined to governmental units on the national level. However, many of our good practice cases demonstrate that initiatives for improving existing e-government services – or creating new ones – may arise anywhere, including the local, regional, or state levels. These initiatives universally require cooperation between units which might have had no direct relationship before. In order to provide guidance for achieving interoperability between systems on any governmental level, we will summarize the findings from our analysis from our special service cases in this chapter. Then, in Chap. 11, we will turn to the issue of setting up more generic infrastructures for achieving interoperability. Particular attention has to be paid to the complex interplay between the political and the IT level, i.e., between governance and IT governance, as well as to the coordination of technical, organizational, and legal changes. We suggest structuring the whole process of setting up interoperable government services into six phases: 1. 2. 3. 4. 5. 6. 7.
Initiation Choosing an IT governance model Choosing an organizational model of service provision Selecting and defining standards Enacting standards Implementing and supporting operation Evaluation and change management.
Figure 10.1 maps these steps. As there is no single best sequence for all the different kinds of interoperability requirements, the arrows only show the most common and most important relations. There are other relations as well, for which no arrows have been drawn, in order to keep the chart simple.
H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_10, # Springer-Verlag Berlin Heidelberg 2011
127
128
10
Strategic Choices for Setting Up Interoperable E-Government Services
Fig. 10.1 Governance of interoperability for dedicated services
10.1
Initiation
Interoperability is not an objective in itself. Rather, it is a requirement arising whenever existing government services are to be improved or new ones have to be created, which involve two or more systems run by different units on the same or on different governmental levels. There are many reasons for such initiatives, and they may arise inside or outside these units, for example, • Benefactors of an existing service may complain about long delivery times, access difficulties, or the administrative burden of providing their same data several times to different units. • Budget cuts may necessitate cost reduction through sharing of resources with other units. • Poor responses to extreme events may lead to attempts to improve cooperation and interoperability. Failures in data exchange or other problems in information flow between units are usually the source of these issues. • Higher-level political bodies on the national or even European level may define legal requirements, which in turn require a rearrangement of processes on the local or regional level to meet new reporting obligations. Quite often the legislators do not – and in many cases do not have the capacity to – define how to implement their demands, or how the required changes match with other processes, available resources, and so on. As manifold are the examples, as multifaceted are the beginnings. In only a few cases is it completely clear who within a unit has to take which concrete action.
10.2
Choosing an IT Governance Model
129
Sometimes, someone in a leading position has to decide where to delegate the task of picking up the initial impetus. Other times, someone within a unit has developed their own idea looking for supporters within the unit, in other units, and/or on the political level. In any case, two things have to be scanned and mapped during the first step: • The service domain, the basic processes involved, and a vision of a distinct goal for the new or improved processes; • The stakeholders affected, producers/contributors to the process, and customers or other parties concerned. This should lead to a specific set of wants and needs for the initiator(s) (see also Chap. 6).
10.2
Choosing an IT Governance Model
Since, by definition, at least two different systems run by more than one unit are affected by the vision, a need for cooperation between units arises. As far as interoperability is concerned, primarily the IT departments in charge have to cooperate. There are different options for organizing such cooperation, otherwise known as IT governance. As mentioned in Chap. 3, there is often an underestimated difference between intra-organizational and interorganizational cooperation, and on the interorganizational level between cases where all units belong to the same governance domain, i.e., federal/national or state/regional agencies, or where they are located on different government levels. When interoperability has to be achieved between processes run by different units on the same level that belong to the same IT governance domain, then the initiator may follow established procedures. There may be a federal/national or state/regional CIO, an IT planning board or commission, or a working group for egovernment. There may also be programs or criteria for cooperative projects. Recommendations to adopt Enterprise Architecture Models for e-government assume this constellation to be the rule. However, many of our good practice cases deal with projects on the regional level or between a few national and local units. In these cases, the initiator has to make a strategic choice. If the initiative comes from a rule-making body, it may either consider whether an existing body, which so far did not deal with issues of the kind at stake, shall be assigned a corresponding task, or whether a new temporary or permanent body shall be established to work on the new vision or goal. In Chap. 9, these different options have been discussed and illustrated by corresponding cases. Because of the manifold occasions and scenarios requiring different kinds of interoperation, it is not possible to assess which option is more favorable than the other. But it is worth stressing that this strategic choice is decisive for the success of all following steps. One important aspect which we identified in our good practice cases, and which is seldom mentioned in IFs and even less in EA models, is the degree
130
10
Strategic Choices for Setting Up Interoperable E-Government Services
of participation or representation of units to be involved in the final roll-out. Several of our cases required that hundreds of local units adopted certain standards or linked up to new registries. It was not possible to have all these units participate in the planning process. But in our good practice cases, some degree of representation was found to be the rule and in our assessment probably contributed to the success of the project. In Sect. 2.3 we emphasized that IT governance deals with the complex relationship between political governance and IT management, including different cultures, frequent misunderstandings, and even outright mistrust. If the initiative comes from the political arena, initiators would be well advised to get into contact with the IT managers of the units concerned (who should have been identified in the stakeholder analysis in step 1). If the initiative arises in the IT management context, CIOs in turn should consult relevant people in the political arena, whose approval will be needed for budgeting and/or legal authorization later on. At this point, a chicken-and-egg problem occurs. The next logical step would be to choose an appropriate organizational model for the new service provision. If no formal or institutional body exists with the authoritaty to make such a decision, however, then such an authority must be established first. But this depends on the organizational model favored by different planning authorities. Or to put it the other way around: Assigning the planning task to a certain authority might well predetermine the outcome, i.e., the organizational model ultimately chosen. As government decisions require budgets and legal authorizations in most of our good practice cases, the legitimization of the (IT) governance model came first, but was taken in light of the organizational model for service provision. The legitimization or authority to set up a new IT governance regime for planning an intergovernmental service provision may be done either by law/ordinance, or by contract/agreement. In Chap. 9 we showed that projects on the national level which required contributions by units on other levels most frequently chose legitimization by law or ordinance, particularly if the units involved were providing the same sort of service for different geographical areas, and existing laws required equitable distribution of that service. On the other hand, contracts or agreements might be generally more open and flexible, and might allow additional units to join up at any point in time.
10.3
Choosing an Organizational Model
Interoperability is mostly associated with selecting or defining kinds of standards in order to achieve a better service provision. We have pointed out that the integration of formerly separated processes or databases into a new centralized system is another option within e-government. This may be more effective and efficient in terms of operating costs and service quality, but often not possible for legal or political reasons. However, with regard to strategic options and choices, it is important to stress that the centralization option should always be checked, perhaps
10.4
Selecting and Defining Standards
131
even by means of a feasibility study. Especially if directories are involved, adherence to the Belgian principle of consulting a single reliable source is worth investigating. Integrity of data and real-time updating can be achieved more easily, effectively, and efficiently this way. The same may be true for setting up integrated workflows under the authority of a central unit. Quite often such options are politically opposed. But we found several instances among our good practice cases where the advantages have been acknowledged and resistance overcome. If technical integration and organizational centralization turns out not to be feasible, an alternative model of organizational federation and technical standardization has to be articulated. This option is much more complex, since not one but many standards have to be chosen and formed into a coherent set of orchestrated standards on the different layers distinguished in most IFs. If a centralization model is feasible and favored, the next step is to look for the appropriate legitimization by law/ordinance or contract/agreement and to define the necessary legal and organizational changes. If the federation/standardization model is chosen, the required standards have to be selected first.
10.4
Selecting and Defining Standards
All IFs list and classify the potential standards to be employed for e-government services. We have chosen a four-layered classification of technical, syntactic, semantic, and business process interoperability standards and could show that complete online fulfillment of e-government services most frequently requires an orchestrated set of standards on all four layers. We have found that standards on the technical and syntactic level are developed and authorized outside the public sector by technical committees, Internet working groups, or de facto by hardware or software vendors, and that therefore any e-government service usually has to choose from available standards. The most critical issue in this regard is the controversial assessment of open versus proprietary standards, mentioned in Sect. 3.1. To reach a decision in this respect, but also for any other choice between different standards, criteria and methods for comparative evaluation should be employed. Many NIFs just recommend a shopping list of several more or less equivalent standards, but neither explains how this selection was arrived at, nor how to choose between equivalent alternatives. As mentioned, Mykk€anen and Tuomainen (2008) have proposed a methodology for selecting standards according to criteria such as scope, functionality, application infrastructure, openness, extensibility and others. We have also stressed the difference between more universal standards on the technical and syntactic layer, in contrast with the domain and content related standards on the semantic layer. Most frequently they are developed within the public sector or its subsectors and therefore open greater discretion. But, in fact, for most of the issues, which have to be standardized, i.e. identifiers, core data, and interfaces, there are already existing implementations which are not easily changed.
132
10
Strategic Choices for Setting Up Interoperable E-Government Services
One important issue at this point is the reusability of ontologies and core directories, stressed in EIF 2.0 and several NIFs.
10.5
Enacting Standards
Selecting appropriate standards is one thing, but implementing them is another. Following Scholl and Klischewski (2007), this gap is expressed by the distinction between interoperability and interoperation. There is a choice between mandatory and optional standards. In our good practice cases, we found examples of open evolutionary strategies offering standardized processes and relying on emerging evidence of their advantages. But we also found cases where obligatory standards have only been enacted by law or ordinance in connection with the provision of format conversion facilities. With regard to the form of mandatory or optional enactment, in some cases a law or an ordinance has been chosen, while in other cases bi- or multilateral contracts or agreement have been negotiated and signed. Again, given the wide spectrum of standards, application domains, and differences in general legislative culture, it is not possible to make blanket recommendations about which methods are more effective for what cases. However, we stress that the complex and challenging interplay between political and the IT management levels is particular virulent. We therefore recommend an intense dialogue between IT managers, who can oversee the barriers to standard acceptance and implementation while assessing the required governance support, and legislators, who may recognize financial implications, compatibility, with existing legal regulations, and other broader issues. Too often projects have failed when such a dialogue has not been conducted, and each side blames the other.
10.6
Implementation and Supporting of Interoperation
While the ideal model of a smooth intergovernmental service assumes the direct interoperation between the systems involved, our cases show that in e-government – as well as in e-commerce – quite often intermediaries are involved. The most prominent kind are clearing centers, which provide directory and routing services as well as formal conversion services. In some cases setting up such a service was a political requirement in order to make a certain data exchange format mandatory. In other cases it was simply a matter of cost comparisons or quality assurance that the centralization of certain support functions was more advantageous compared to decentralized fulfillment by every participating unit. In contrast to the central provision of the e-government service for citizens or businesses, the central provision of support functions does not touch the distribution of authority between governmental offices. In some of our good practice cases, these functions have been assigned to governmental IT service units, while in other
10.7
Evaluation and Change Management
133
cases they have been completely outsourced to commercial service providers, often called Value Added Network Providers (VAN Providers). In some cases these services were provided in public-private partnership. Whatever organizational configuration is chosen, we strongly support the recommendation of EIF 2.0 to regulate the provision of these supportive functions by service level agreements. This recommendation is not only directed to outsourcing cases, but also explicitly to cases where governmental IT services are to be provided. Service Level Agreements allow for more reliable planning, and they provide yardsticks for evaluation – at least of the support functions.
10.7
Evaluation and Change Management
We add one final phase to the life cycle of achieving interoperable e-government service, and that is evaluation and change management. However, this phase was not present in our cases. Given the high degree of uncertainty in making the choices described so far, it is quite likely that they have not reached the optimum with respect to every issue. Therefore, great potential exists for improvement which could be identified by an evaluation after 2 or 3 years. Yet, IT controlling, including the external outcome and impact, is still not common in e-government. Even more critical is change management of standards. Standards provide stability and predictability but also a certain rigidity at the same time. They have an inherent capacity of slowing down technological and organizational progress. New versions of standards night need to be employed but also competing and even superior standards might emerge. Sometimes this may be a mere technical issue, which can be solved by providing a conversion service between the old and the new version. But new versions or new standards may allow improvements in processes or new options for customers, perhaps in connection with organizational changes. Then the whole cycle may be started again. In summary, IT, administrative, and political leaders in government need to address and understand the strategic choices interoperability and interoperation, in particular, in interorganizational and cross-level settings. We propose an orchestrated and structured approach, which includes seven steps from (1) initiation, (2) determining the IT governance model to be adopted as well as (3) the organizational model, (4) determining and (5) enacting the standards to be used, to (6) implementation, and, finally (7) evaluation and potential standard overhaul and organizational-model revision in such projects. Intra- and inter-organizational interoperability and interoperation in government are highly dynamic undertakings, which need to take into account the half-life of any standard settings. In other words, the proposed approach should be interpreted as a feedback loop rather than a linear and sequential path.
.
Chapter 11
Interoperability Beyond Interoperation
So far, we assumed that for setting up a new or improved electronic public service, actors from different government units would select or develop interoperable components of these particular services. We have called these cases “specificservice cases”. For these cases we could identify certain patterns in political and IT governance summarized in the previous chapter. But in our sample we also found infrastructure and portal cases. In these cases, actors wanted to create interoperability beyond an individual service. They wanted to develop a system that would provide several services or be used for several different services without necessarily knowing at the time of development what all those services would be at a future point in time. In recent years, in literature on the subject and also indicated through the progress from EIF 1.0 to EIF 2.0, we observe a shift of emphasis in recommendations, methods, and tools from specific-service interoperation to more generic methods and tools aiming at interoperability of an open number of different services. We may thus speak of interoperability at a meta-level. This can be done in either a top-down fashion by defining and deploying abstract and formal components, or in a bottom-up approach by developing these components for a particular service or group of services in a way that allows re-usability for other services in the future. Typically, the top-down approach starts with an Enterprise Architecture or a Reference Architecture (Janssen et al. 2011, p. 100). The recent publication on interoperability research by Charalabidis (2011) includes a number of articles on generic components. A bottom-up strategy follows the principle of reusability as laid down in EIF 2.0. Examples are the Belgian Cross Roads Bank, the Irish child allowance based on the Public Service Broker, or the German civil registry X-Meld case. In these cases, interoperation was achieved for one or a few services, but the technical and organizational components were supposed to be reused, and actually were reused, for additional services later on, to various degrees.
H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_11, # Springer-Verlag Berlin Heidelberg 2011
135
136
11
Interoperability Beyond Interoperation
Scholl and Klischewski (2007) speak of interoperability beyond interoperation, pointing to the significance of “ability”, which goes beyond the individual act of creation. In this chapter we discuss how and to what extent this foreseeing and sustainable interoperability can be achieved, considering and drawing from our good-practice cases.
11.1
Interoperability as Capability and Generic Components
Recent recommendations for developing interoperability strategies emphasize the need for building up permanent flexible capabilities and reusable building blocks. Such an approach was recommended in the EPAN Framework and included the definition of organizational interoperability: Organizational interoperability “is concerned with the coordination and alignment of business processes and information architectures that span both intra- and interorganizational boundaries. (. . .) It is suggested that administrations could develop an exemplar scheme that would define standard approaches to each of the main requirements of any public service (. . .); that common functionality could be provided on a shared basis through a broker service to reduce development, deployment and operational costs to the public administration and to each service fulfillment agency, and to ensure consistency of experience for users of services across all agencies in the public sector through the use of agreed standards across all services; (. . .); and that each administration could develop a central program of organization development assistance and funding to bring this change about.” (EPAN 2004, pp. 5f.)
Scholl and Klischewski (2007) distinguish application-specific and general approaches to interoperability and consider the move from the first to the second as a “leap of technical and organizational development”: Interoperability enacts higher states of both technical and organizational readiness for interoperation. Given the expectation of frequent and multi-lateral interoperation in the future, interoperability also denotes an e-government policy goal of overcoming the need for lengthy negotiations and specific arrangements prior to establishing any peer-to-peer interoperation. (2007, p. 901)
They call this higher level of interoperability dynamic and flexible and expect it to occur most frequently in federated institutional settings (p. 902). Similarly, Pardo and Burke conceive of interoperability as a “core capability for connected government” and the presence of these capabilities as an “advanced stage in e-government” (Pardo et al. 2011, p. 3). They distinguish seven categories of capabilities to allow for an assessment of e-government maturity (p. 6): • • • • •
Business architecture, Governance and leadership, Strategic management, Operational management Information policy,
11.1
Interoperability as Capability and Generic Components
137
• Cross-organizational collaboration, • Technical readiness. In another paper, Pardo and Burke present a multi-level government interoperability maturity model with three levels (Box 11.1): They are well aware that so far there are successful cases of governments Box 11.1: Government Interoperability Maturity Levels Level 1: There may be evidence of interoperability within individual government organizations, but there is little to no evidence of any interoperability across agency or organizational boundaries. At this level, government agencies work independently and do not share information with other organizations; government or private sector. In addition, there is little evidence of the decision making, strategic planning, and resource and project management structures and processes needed to develop and manage ongoing or future initiatives requiring improved government interoperability. Level 2: There is evidence of interoperability in specific policy or program areas. However, there is little evidence of interoperability across multiple networks (e.g. criminal justice networks cannot share information with public health networks). In addition, while interoperability initiatives in these areas may be planned and managed in a consistent way, the process for selecting, controlling, and evaluating initiatives is not consistent or standardized across networks or at a government-wide level. Level 3: There is evidence of interoperability across multiple networks. For example, public health and criminal justice networks can effectively share information across their two networks in support of the larger policy goal of public safety. In addition, consistent and standardized processes and structures are in place to develop and manage government interoperability initiatives regardless of policy domains. As a result, existing networks can scale and apply resource sharing and process integration across multiple policy and program areas as needed, essentially creating new networks.
reaching level 2, but not level 3: Many governments have developed successful interoperability in individual policy areas such as criminal justice, public health and environmental protection, or in various e-government areas such as integrated accounting systems and online tax-filing and educational resources. However, there is little evidence of any government that has demonstrated the level of government interoperability that brings together multiple policy domains in support of a broader citizen need, for example, creating interoperability between the criminal justice and public health communities in support of more effective public safety. (Pardo and Burke 2008a, p. 3)
In a briefing paper for e-government leaders, the two authors use an Information Sharing Complexity Matrix, developed by Gil-Garcia, distinguishing three levels of
138
11
Interoperability Beyond Interoperation
Fig. 11.1 Information sharing complexity matrix (Pardo and Burke 2008a, p. 8)
organizational requirements for program-specific and “enterprise”-related interoperability (Fig. 11.1). The chart assumes that there is increasing maturity and successful management of complexity by moving from providing for interoperability of single services within an organization via program-specific provisions between organizations, finally reaching a common enterprise architecture across different levels of government. This assumes that agencies from different levels of government have agreed on common standards, re-usable generic components and shared services for achieving interoperability for all of their services and business processes. Based on this framework they make several recommendations to egovernment leaders to set up effective cross-boundary governance structures and enterprise resource allocation models (Pardo and Burke 2008b). The first observation regarding existing level-two inter-organizational interoperability achievements applies to the European e-government landscape as well. Based on our cases we discuss below whether level three, multi-domain interoperability, might be achievable at all. In our sample, a few cases fit the requirements of dynamic and generic interoperability provisions. But as observed by Prado and Burke, they all focus on a single policy field domain and were not successful when transferred to another domain. These cases also represent different strategies towards generic interoperability provisions. The Belgian Cross Roads Bank case (see case no. 4) shows a typical top-down approach. More than 100 types of messages exchanged between dozens of organizations were reduced to three message types. Other organizations can connect quite easily, and take advantage of services for routing, identity validation, and many more – but only within the social welfare policy domains (i.e., between employers, employees, and service providers). When Frank Robben, the architect and top manager of the Cross Roads Bank, was asked in 2009 to develop a similar clearing center for the health sector (i.e., the exchange between doctors, hospitals, and health insurance bodies), he did not suggest extending and reusing the Cross Roads Bank components but started something similar with the respective circle of stakeholders and employed new semantics as well as a new organization. In the German X-Meld case of civil registration (see case no. 3), a slightly different strategy was applied. Within the IT cooperation body of national, state,
11.1
Interoperability as Capability and Generic Components
139
and local government (KoopA ADV), the decision had been made to adopt and further develop a general standard for secure message exchange within e-government called OSCI (Online Services Computer Interface). The OSCI architecture distinguishes a universal transport layer (OSCI transport) from an application-specific service layer in XML format. KoopA ADV agreed to establish and jointly fund an OSCI control center, developing OSCI transport and afterwards application standards on demand. The first application was the exchange of civil registration data between local registration offices as mentioned before. The message format X-Meld had been enacted by the permanent Conference of the Ministers of the Interior of the 16 German federal states (Bundesl€ander) and the Minister of the Interior at federal level, and was finally made mandatory by a revised version of the existing ordinance for data exchange and registration. Attempts to establish and implement a similar standard for the registration of companies (X-Gewerbe), however, failed. Neither technical nor organizational differences between the existing local and regional systems were to blame for the failure, but rather an organizational gap at the political level and a lack of political pressure prevented the project from achieving a common standard to interlink the separated systems. The development and implementation of X-Meld was initiated by a representative of one of the larger federal states who had longtime personal relations to several CIOs of other federal states and pursued this objective with great personal engagement. As he also had been involved in former initiatives concerning civil registration he also knew, which political bodies and politicians had to be approached to achieve political support and finally political consensus. The relevant body was the permanent conference of the Ministers of the Interior at national and federal level. This governing body had created a long tradition of harmonizing processes in the areas of civil security, exchange between state police agencies, and emergency management among others. Access to civil registries by police was part of the common interest and tradition of cooperation, because police officers in any federal state had to have access to all local registries in order to check on the identity of people under suspicion. In contrast, the registration of companies belongs to the jurisdiction of State ministries of economic affairs who do not have similar common interests and a tradition of cooperation. Rather, they compete for the settlement of companies. A working group produced a draft for X-Gewerbe, but there were other competing initiatives as well, and in the end no political decision was made to adopt it. The German X-Meld case, however, also showed us that technical components could be reused to a certain degree, but that when interoperability was needed in a different domain, different stakeholders became relevant and also new federations with new agreements became necessary. In addition, on the semantic and business process layers, reusability of components is, in any case, different and possible to a lesser extent than on the technical and syntactic layers. In the Irish child benefit case (see case no. 1) the Department for Social and Family Affairs started a Service Delivery Modernization Project (SDM) to redesign business processes through the introduction of new technology. In parallel, the National Register Office started the Civil Registration Modernization Programme
140
11
Interoperability Beyond Interoperation
to organize registration around life events. Reach, the IT service provider for national government at the time, worked on Reach Interoperability Guidelines (RIG) and saw a chance to develop and implement a pilot case for the Public Service Broker in redesigning the process of applying for child benefits through an automatic multi-stage business process with a similar architecture as OSCI. Besides the vertical integration of hospitals, registrars, civil registries, and the office for family affairs, a similar chain was established for death certificates and marriage certificates. While technical and syntactic standards could be applied to this second field of application, semantic and business process related standards as well as legal adaptation had to start all over. The three cases illustrate that the contingency of actor constellations and political contexts is a highly crucial factor when striving for generic interoperability. Before context-dependent technical components can be transferred from one policy field to another, the process of identifying and involving decision-relevant authorities as mentioned in Fig. 10.1 needs to get underway successfully. And as the German case showed, the actor constellation and perceived political pressure could greatly vary with very tangible effects. In the absence of universal cooperation agreements between all government agencies at all levels, the enterprise metaphor recommended by Pardo and Burke does not appear as an appropriate representation of the institutional and political realities in the public sector. Instead only a few clusters of agencies tied in via cooperative agreements exist, which also expose some overlapping. And even within one domain or at one level, multi-context memberships cause conflicts. A good illustration is given by the Danish OIO-XML case. A group of experts in the Ministry of Science developed an enterprise architecture for the communication and exchange of messages in government between agencies at the national and local levels, while the Ministry of Finance was responsible for e-government and IT investments. The Ministry of Science had hoped to gain greater influence by developing this standard but depended on the blessings from the Ministry of Finance, which did not dare making the standard mandatory even for the ministries at the national level. As Hjort-Madsen and Pries-Heje (2009) report from interviews with different CIOs in Danish government that the new standard found little acceptance in some ministries not because of general resistance to change and power plays, but because of multiple memberships in different networks or federations. The representative from the Ministry of Foreign Affairs pointed out that interoperability with EU and NATO standards for this ministry was far more important to the Ministry than interoperability with other Danish entities. The CIO of the Directorate of Agriculture, Fisheries, and Food stressed that his organization had emerged from a merger of several formerly separate agencies, and that he had just established interoperability within this new institution and, hence, was unwilling to jeopardize this accomplishment for the sake of a better interoperability between all ministries and local governments. Following the tendency towards networked government, government leaders have to develop networking and collaborative capabilities. However, this will be
11.1
Interoperability as Capability and Generic Components
141
unlikely lead to one large and unified network across policy domains and levels of government; instead, it is much more likely this to take the form of a great number of partly overlapping networks. Accordingly we expect a number of federations with multi-membership of public agencies and links to different joint networks with different private-sector branches to emerge trying to establish interoperability within different networked systems. Individual agencies with multi-membership have to either set priorities or operate different standards in parallel. For addressing technical networking issues the Internet as the Network of Networks proved a robust solution, and also on the syntactic level we find a whole host of even universal standards. However, based on our investigation we squarely doubt the possibility of similarly universal semantics. This vision upheld in some parts of computer science appears illusory to us and even detrimental when advanced in recommendations for interoperability in government. We assume instead that semantic, organizational, and legal issues have a strong context dependency, and that we have to keep living with the resulting complexity and conflicts. The high degree of conformity, which may be considered high maturity in computer science, could be achieved in the real world of government only in more centralized and outright authoritarian political structures. Therefore, overlapping domainspecific federations are not a disadvantage, but an expression of a lively democratic government landscape, which we would not like to exchange for a bit more productivity and efficiency.
.
Chapter 12
Conclusions and Outlook
For decades and among other principles, the jurisdiction of public administrations has been organized according to the principle of geography. Hundreds or thousands of local municipalities provide the same public services to citizens and business according to the same basic rules with only few variations. This organizational structure is proven and exists for good governance reasons. Following the proximity principle, citizens should have easy access and need limited effort for getting in contact with their administration; and the administration should be familiar with the constituency. In the virtual world government services become available at citizens fingertips but only if agencies work together, coordinate their processes, and make their ICT system interoperable. Until recently, interoperability has been considered a problem of technical integration or technical standards. National governments and the European Commission proposed and advanced Interoperability Frameworks (IFs) in order to provide guidance in the process of developing or selecting standards for electronic government services. The research reported in this volume tried to assess, to which extent these frameworks address the practical situations and arsing challenges when interoperability is to be achieved across branches and levels of government. In particular, the terms “organizational interoperability” and “governance” were emphasized in official documents as key aspects but remained remarkably fuzzy. As a consequence and based on a relatively high number of good-practice cases, we distinguished and studied strategic choices for the governance of interoperability in government. We began the discussion by revisiting the historical beginnings of computer networking and integration and the role of IFs as guidelines for ICT procurement. As we demonstrated, interoperation of information systems and integration of workflows and business processes required a number of other provisions and prerequisites, which went far beyond the functional technical dimension. As we also illustrated by several cases of successful interoperation, interoperability in e-government needed to regard the various organizational models involved, which, in turn, were governed by provisions, rules, regulations, statutes, and laws, all of which might change over time. Quite often projects were initiated by agencies, H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4_12, # Springer-Verlag Berlin Heidelberg 2011
143
144
12
Conclusions and Outlook
which were part of separate jurisdictions, so different, and even incompatible models of governance might have been involved. Finally, we found that interoperability projects in government could not be divorced from the political and publicpolicy context, in which they were embedded. In other words, while the functional side of interoperability already provided quite a few challenges in its own right, the embedding contexts appeared to pose even more complex problems and challenges. We used 77 cases to analyze and deconstruct (at least in part) the complexities of interoperability projects. We found that such projects in government were complex and risky. However, despite the challenging nature they could be planned, implemented, and operated successfully. Yet, we maintain that interoperability will remain a huge and ongoing challenge, which needs close attention and deep understanding of the variables involved. Interoperability in government needs a resilient and flexible model of IT governance, which helps advance the political, institutional, and functional opportunities over time. This holds not only true for the output and outcome of interoperability projects but also for the institutional setting, i.e., the kind of institution to be commissioned with planning tasks, and the kind of compliance regime to be enacted. There is no one-size-fits-all type of IT Governance structure for interoperability in the government of a nation, bur rather governance structures have to be newly established when agencies from different levels and branches of public administration have to work together to provide a particular service or share resources. Governance of interoperability in government requires a permanent innovation, each time a risky adventure with limited learning effects since cases may greatly differ in terms of context and stakeholders. Our view challenges part of the recent literature. Some researchers as well as consultants consider this trial and error business to be ineffective and propose to learn from the private sector and establish Enterprise Architectures, a kind of standard model for standardization. We have expressed our skepticism regarding the straightforward introduction, implementation, and operation of commercially inspired strategies and structures of IT Governance. Even for the private sector these architectures are models and blueprints rather than reality. Chief Information Officers very rarely achieve full compliance with such architectures in all parts of an enterprise. Interoperability in government goes beyond a conglomerate of permanently related companies. It resembles a network of organizations agreeing on a joint venture with each organization participating in several other joint ventures with different partners at the same time. We do not know of any enterprise architecture implemented successfully over such a multi-joint venture conglomerate. But even if this could be accomplished in the private sector for its more hierarchical organization optimized to serving the bottom line, we maintain that models of corporate governance when applied in the public sector can get into conflict with basic democratic principles, in essence, with the very “architecture” of the democratic State. Lawmakers, when enacting legislation for interoperability in government need to understand that such architectures might have the capacity to alter the very nature of the democratic system. We assume that the introduction of
12
Conclusions and Outlook
145
Enterprise Architectures Systems, if accepted at all, will increasingly meet stiff resistance from various stakeholders inside and outside government who would not be willing to waive their mandates and obligations to represent their constituencies for the sake of gains of operational efficiencies and economies. When IFs so far mention a political layer or a political dimension of interoperability they only refer to negotiations between policy makers from different political parties, parliamentary debates, etc., but probably not to the possible interference with basic democratic principles. The Western-style model of democratic self-governance “of the people by the people for the people” rests on certain principles, some of which are worthwhile mentioning in the context of interoperability projects: (1) government is supposed to be limited; (2) governmental powers are to be divided; (3) an effective system of checks and balances needs to be put in place, (4) government action are subject to judicial review, and (5) the rule of law is upheld. The underlying constitutional idea strives for establishing and maintaining an effective, but not an efficient government. Powers are meant to remain limited and checked such that stakeholders have a part in decisions pertaining to them. Interoperability extends way beyond the mere functional realm of technical, syntactic, semantic, or business process standardization. Observably it has immediate impacts on the political, the public policy, and administrative contexts. It might even have a capacity to impact the constitutional model of governance in unanticipated (and undesired) ways potentially offsetting some safeguards put in place in the democratic system. For example, a routinely unconstrained exchange of information and interoperation between government agencies that were once separated by law might lead to such an effective coordination of government action that the separation of power de facto ceases to exist. While interoperability undoubtedly can help improve government services and reap a plethora of gains that benefit the public good and the democratic system, interoperability research must also cast an eye on the maintenance of constitutional safeguards or their replacement by such safeguards, which are capable of coping with the emerging interoperability reality in government. Scholl and Klischewski (2007) proposed to explicitly include outcome analysis into the interoperability research agenda. Among others the authors distinguished two outcomes of interoperability projects, which research should concern itself with: (1) “type A” outcomes (results desired/project successful) and (2) “type B” outcomes (results undesired/ project successful). In our study, we have admittedly solely focused on “type A” outcomes. This was not possible to consider “type B” outcomes in this study because the cases analyzed had been collected and selected as examples of project successes and of good practice. However, for future studies, we will recommend and try to also assess and understand what undesired side effects interoperability has already produced or might be able to produce. Only then a comprehensive and valid analysis and assessment of networked government will become possible.
.
Annex 1: List of 77 Good-Practice Cases
Country Name of case Integration cases AT Central register of residence AT e-file including e-signature – land acquisition by foreigners BE Management of school transportation in the walloon region CZ Center of timely intervention system of timely intervention (SVI) DE Virtual construction platform DE The Bavarian Junior Highschool Network DK ETHICS – Electronic Tendering, National Procurement Ltd. (SKI)
ES FI FI FR
GR
NL NO
InfoVille 21 TYVI service and environmental pollution announcements The finnish address system e-Bourgogne – regional shared e-government. The example of the eProcurement platform in Burgundy/France E-oikonomia web portal
Dutch centre for vehicle technology and information (RDW) Primar stavanger, electronic navigation for sea transport
IDa
Case owner Austrian Federal Ministry of the Interior Vienna City Administration Walloon Ministry for Equipment and Transport Ostrava City Administration
96 98 1
108
Esslingen City Administration Bavarian Junior Highschool Network
20 28
National Procurement Ltd. Denmark (SKI) – owned by the Ministry of Finance and the National Association of Local Authorities, Denmark Valencia Region Administration Finnish Ministry of Environment
35
Finnish Ministry of Interior – Population Register Centre Burgundy Region Administration
7 17 149 146
Greece Ministry of Economy and Finance – General Secretariat of Information Systems Dutch Centre for Vehicle Technology and Information (RDW) Norwegian Hydrographic Service
21
25 37
(continued) H. Kubicek et al., Organizational Interoperability in E-Government, DOI 10.1007/978-3-642-22502-4, # Springer-Verlag Berlin Heidelberg 2011
147
148
Annex 1: List of 77 Good-Practice Cases
Country Name of case NO Universities and colleges admission service UK LETS – Leeds Electronic Tendering System UK Street works information
Case owner Universities and Colleges Admission Service (UCAS) Leeds City Administration
IDa 120
Jakobs (private company) on behalf of local authorities in UK
130
34
Specific-service cases AT AT AT AT BE CH DE DE DE
DK DK DK
DK ES ES
FI FI FR FR IE IT
IT
HELP – virtual guide to Austrian authorities and institutions Certificate of residence PAWA – Paperless import administration Social code of re-imbursement Belgian social security benefits for citizens The Geneva internet voting application Starter-center Karlsruhe Federal education assistance Civil registration in German regions – the example of lower Saxony My student fund (“My-SU”) Bibliotek.dk Netborger.dk
Federal Chancellery of Austria Federal Chancellery of Austria Austrian Federal Ministry for Economic Affairs and Labour Main Association of Austrian Social Insurance Institutions Crossroads Bank for Social Security in Belgium Geneva State Chancellery Karlsruhe City Administration German Federal Ministry of Education and Research German Federal Ministry of the Interior
8 9 10 154 11 38 93 110 136
Danish Education Support Agency 12 Danish Bibliographic Centre 13 14 KMD (private company, owned by the National Association of Local Authorities, Denmark) Electronic invoicing in Denmark Danish Ministry of Finance, Agency 87 of Governmental Management Citizen income tax Spanish Tax Agency 26 The integration platform Consortium for Electronic Administration 131 in Catalonia (Administracio´ Oberta Electro`nica de Catalunya) Crime declaration on the internet Finnish Ministry of Interior – Police 15 eInvoicing in Finland – the example eInvoice Consortium with main actors 151 of the region of South Karelia in Finland and TIEKE Dossier medical d’Urgence en GIP-Tele-medicine of Picardy 3 PICardie CFENet: centre for company Assembly of French Chambers of 124 formalities on the net Commerce e-Enabled child benefit service Department of Social and Family Affairs 22 23 Auto e-Counter Italian Ministry of Infrastructure and Transport together with Automobile Club Italy (ACI) InfoCamere – registration of a new Infocamere (IT consortium of Italian 24 company Chambers of Commerce) (continued)
Annex 1: List of 77 Good-Practice Cases
Country Name of case IT Sistema di TRAnsito Doganale Automatizzato IT Regional integrated health services for the continuity in the medical treatment in Friuli Venezia Giulia NL Kadaster-on-line. Direct access to land-registry products via Internet in the Netherlands PL Customs declaration systems PL Integrated system of polish national registries SE AX – single window solution for eApplication for export refunds and eExport-declaration SE Company registration eService in Sweden UK The road traffic accident automation project in UK UK
149
Case owner Italian Customs Agency
IDa 45
Regional Health Agency of Friuli Venezia Giulia
140
Dutch Land Registry Office (Kadaster)
138
Polish Ministry of Finance Department of National Registries, Poland Swedish Customs together with Swedish Board of Agriculture
Swedish Company Registration Office together with Swedish Tax Agency UK’s Department for Work and Pensions – Compensation Recovery Unit DWP’s real-time pension forecasting UK’s Department for Work and Pensions
5 6 127
139 85
129
Portals AT
EE
The e-government portal of Salzburg country FEDICT – federal portal for citizens and business Electronic gateway for online administrative services in Stara Zagora Bremen online services HamburgGateway – the digital gate to the city eID in Estonia
ES
CAT365 Citizens’ Portal
ES
Tax Information between public administrations, Agencia Tributaria, Departamento de Informatica Tributaria GENERALITAT EN RED (Generalitat online) Individual entrepreneur certificate system (EVIG)
BE BG
DE DE
ES HU
Salzburg State Administration
29
Belgian Federal Government
32
District Administration Stara Zagora
94
Bremen City and State Administration 79 Ministry of Finance of City and State 100 of Hamburg 150 Estonian Government’s Citizen and Migration Board together with a private joint venture (AS Sertifitseerimiskeskus) Consortium for Electronic Administration 39 in Catalonia (Administracio´ Oberta Electro`nica de Catalunya) Spanish Tax Agency 63
Valencia Region Administration
106
Hungarian Ministry of the Interior
113 (continued)
150
Annex 1: List of 77 Good-Practice Cases
Country Name of case IC My Gardabaer – an integrated citizen portal and municipal case management system IE The public services broker (www.reach.ie) IT Carta d’Identit Elettronica – Electronic ID Card in Parma IT Digital Cartography – OUT OF THE BOX South Tyrol IT IT
eJPA – eJustice Point of Access Utilities project
IT
Applications for interoperable digital administration Mobile government infrastructure
MT MT NL RO SE UK
Case owner Gardabaer City Administration
IDa 84
Reach agency – the cross-departmental agency established by Government Parma City Administration
117
Autonomous Province of South Tyrol – Office for spatial and statistical informatics Italian Ministry of Justice Turin City Administration and CSI Piemonte Livorno City Administration
36
Maltese Ministry for Justice and Local Government The corporate data repository Project Central Information Management Unit (CIMU) of the Government of Malta Gemeente Pragmatika EGEM (private company) on behalf of local governments SOMCET-Net – transport ICI – National Institute for Research and optimisation for eBusiness Development in Informatics F€oretagarguiden (The Swedish Business Development Agency entrepreneurs guide) Sheffield public data web Sheffield City Administration
30
43 44 60 31 119 133 33 128 77
Infrastructure components AT AT
ELAK im BUND Standardized e-Form exchange via EDIAKT II in Austria The Danish OIO-XML project
Federal Chancellery of Austria Federal Chancellery of Austria
89 135
Danish Ministry of Science, Technology 142 and Innovation – National IT and Telecom Agency 147 CISIS, the association of Regional IT System for e-Enabled cooperation Authorities for statistic and among regional, local and IT matters national administrations in Italy UK Accessible and personalized Partnership between five London 64 local authority websites Boroughs UK ESD – Electronic Service Delivery Improvement and Development 67 Toolkit Agency in the UK a ID refers to the case number in the interoperability case data base at http://www.egov-iop.ifib.de
DK
Annex 2: Summaries of Good-Practice Cases
For cases mentioned in the text, according to the sequence of reference, short summaries are given. ID refers to the Case Number in the interoperability case data base at http://www.egov-iop.ifib.de, where extensive case descriptions are provided.
No. 1 (ID 22): e-Enabled Child Benefit Service, Ireland The Irish child benefit e-service enables initiation of child benefit claims automatically and proactively for all new births in Ireland. Moreover, it eliminates the need for customers to submit a physical birth certificate when making a claim for child benefits for a new babixy. This process required back-office and IT system developments in both the child benefit and civil registration services, as well as the development and implementation of a conduit for electronic notification of birth registrations from the civil registration service to the child benefit service. From the perspective of child benefit services in Ireland, three related initiatives – redesign of the child benefit (CB) system, modernization of civil registration (GRO), and inter-agency linkage and messaging system (IAMS) – were important. The Irish child benefit service is the first e-government development in Ireland that e-enables life event data, to the benefit of both customers and the public service providers. It is part of a wider Irish program to e-enable life-event data more generally. The foundation of this program is the development of the “Public Service Broker” (PSB), which is currently under way with the view to fully leveraging the potential of e-government concerning the use of life-event data.
No. 2 (ID 26): Citizen Income Tax, Spain The Spanish Tax Agency (AEAT – Agencia Estatal de Administracio´n Tributa-ria) enables tax citizens to complete and deliver the income tax return including payment via its web site. The digital signature is needed to complete the whole 151
152
Annex 2: Summaries of Good-Practice Cases
process online; however the main part can also be done without the signature. The taxation service is provided by a range of authorities starting from the local tax offices, social security institutions to the AEAT which links all with taxation concerned authorities and most of the companies providing individual tax information and includes them into the tax declaration of the citizen. This data is then being provided on the portal. The tax citizen only has to log in to the tax portal and download this information in order to put it into the individual declaration form. If necessary, the tax citizen can amend the data and finally send it back signed with a digital signature. This means, the user can deal with the whole declaration process through Internet, not needing other procedures on paper. All processes are automated. The payment process in case of refund or of additional payment is also integrated in the automated workflow.
No. 3 (ID 136): Civil Registration in German Regions: The Example of Lower Saxony The civil registration in Germany is characterized by its federal structure. The State provides the guidelines for civil registration, the states (“L€ander”) are the legislators that convert these framework conditions into federal acts, and the local registration offices are responsible for service provision. This has led to many differences in the proceedings and processes used among the registration offices. To overcome this structure, regional initiatives emerged using standardized formats to enable electronic data exchange among civil registration offices; first within the borders of the Federal States and then, under the influence of two meanwhilelegalized standards for data-exchange and civil registration messages, across the regional borders. What started differently in the various Federal States due to different software systems, legislation, and financial resources turned into a rather coordinated project within Germany, called XMeld. The content-related standards for messages and proceedings in the civil registration are defined by a standard called OSCI-XMeld. To securely exchange these messages among citizens, businesses, and administrations, a special transport mechanism is needed. This mechanism is described and standardized by the OSCITransport protocol. Both standards together are referred to as “XMeld”. XMeld has implemented vendor- and product-independent solutions in order to execute the amended German law. The basic principle of the XMeld project is the bilateral exchange of registry data between citizens and the public administration, and among public administrations, via the OSCI-Transport protocol. To exchange digitally signed messages in accordance with the German Signature Act, this protocol has to be endued with cryptographic mechanisms. In addition, the messages have to be structured so that subsequent processing of the messages is possible without any cross-media conversion. This is enabled by the OSCI-XMeld standard, which is the basis for the integration of registry data in different systems.
Annex 2: Summaries of Good-Practice Cases
153
No. 4 (ID 11): Social Security Benefits for Citizens, Belgium In Belgium, about 2,000 federal, regional, and local public or private institutions are entrusted with social missions and are responsible for granting social benefits. This includes government bodies (e.g., public social welfare centers) as well as private organizations (e.g., health insurance funds or unemployment agencies). These institutions provide services (e.g., assistance relating to job searches or health care) or grant financial support (e.g., benefits or tax deductions). Public social welfare centers (“CPAS”), which are located in each municipality, must provide citizens with help through different life events, therapeutic measures, the prevention of difficult life situations, and substantial support measures. The social services in Belgium are organized in such a way that those services regularly concern several government levels. For example, even if the service provision is local, other government level offices might have to be consulted to carry out the service; this most often concerns verification of the applicant’s data. This approach can be attributed to one of the basic principles of administrative practice in Belgium: that citizens should only have to give information once to the public administration. This means that the public administration in need of this particular citizen data has to ask for the up-to-date data of this citizen at other public administrations that already have this data. However, since the responsibilities for services are shared among the various government levels, this makes it especially difficult and inefficient for the single CPAS to get up-to-date citizen data from these various databases. This challenge has been answered with the interposition of an institution (the Crossroads Bank for Social Security), which connects the back office applications of the various offices concerned to social services. The local CPAS use this network for the verification of applicants’ data, which is the basis for the entitlement and calculation of social benefits.
No. 5 (ID 139): Company Registration E-Service, Sweden The company registration e-service “Foretagsregistrering” is a single place for the registration matters of companies. The e-service provides a one-stop-shop for electronic registration. Before this e-service, users had to submit two different registration forms to two different organizations – the Company Registration Agency (Skatteverket) and the Tax Agency (Bolagsverket) – sequentially. With the new e-service, data fields to be entered in the forms have been aligned, and by entering the company registration information in the website foretagsregistrering. se, the data is sent in parallel to Bolagsverket and Skatteverket.
154
Annex 2: Summaries of Good-Practice Cases
No. 6 (ID 96): Civil Registration Services, Austria Civil registration and other e-government services in Austria rely on a central repository containing the personal and residence data of all Austrian residents – the Central Register of Residence (CRR). The CRR is the logical consequence of Austria’s efforts to streamline the public service provision towards an organization providing a rather centralized infrastructure for decentralized usage, and creating synergies among different services in e-government. In this sense, the CRR is the core of all public services offered to citizens where up-to-date residence information is needed. The CRR was developed by a newly-founded organization, the Support Unit ZMR (Zentrales Melderegister). This unit by law is responsible for overall project organization and the maintenance of the Central Register of Residence, and serves as contact point for the associated public authorities. The local registration offices (responsible for registering and updating residence data) and the Registrars’ Offices (responsible for registering persons) are connected to the CRR. The local authorities administer their registries and feed the CRR in parallel. Since the municipalities record the residence data of persons living in Austria, all 2,359 municipalities are connected to the CRR. In realizing the CRR project, more than 40 different software providers who had supplied local software solutions to the public authorities had to be supported in implementing the new XML interfaces. Now the connected public authorities have access to the CRR through a central server network via the Internet. To guarantee security, a multilevel access and security concept has been implemented. Furthermore, every transaction is recorded in a protocol to allow tracing it at any time.
No. 7 (ID 13): Bibliotek.dk, Denmark Bibliotek.dk is a service that enables the user to access the total amount of books in Denmark. If the user identifies a book that he wishes to lend he may specify the library that he wants it to be delivered to. The user may use his personnel number to identify himself and secure that he is the one he claims to be. Once the book is collected at the library the user will have to use his library card, or health insurance certificate to lend the book. The service has fundamentally changed the way that citizens may interact with libraries. They no longer need to speak with expert personnel to locate and order books that aren’t present at their local library since they can access the entire “population” of books in Denmark through the Internet and order them. This has lead to significant changes in the back-office of libraries. First and foremost the traffic and lending generated by the system has meant that many of the employees have had to develop new ICR competencies. In an organizational perspective the introduction of the system has accentuated a trend towards a de-specialization of
Annex 2: Summaries of Good-Practice Cases
155
librarians as means to improve flexibility and customer service. Both end-users and librarians have been involved in the various development phases of the project. The case ties all Danish libraries together and offers a service that is significantly better and more efficient for all involved parties. Seen from administrative, technological and project management perspectives the service is also interesting because it is an example of a centrally developed initiative that manages to include more than 500 local actors that has very different organizational and technological set-ups.
No. 8 (ID 85): The Road Traffic Accident Automation Project, UK The Compensation Recovery Unit (CRU), part of the Department for Work and Pensions (DWP) in Great Britain, recovers hospital costs for the treatment of injuries arising from road traffic accidents (RTA) from Insurance Compensators, on behalf of Department of Health. This was originally a high-volume clerical processing operation, dealing with 350,000 forms annually (equating to 700,000 transactions) issued between the DWP, CRU, and National Health Service (NHS) Hospitals. Through cross-government cooperation, the full process has been automated over the Government Secure Intranet (GSI). The data previously issued in paper format from the CRU system is transferred to NHS Hospitals as an eXtensible Mark-up Language (XML) schema and displayed on their web server. The required enquiry data is input by the Hospital administration staff via a web browser, and the response is transferred back to CRU for automatic update of its system at a muchimproved turnaround time. On receipt of the returned RTA forms, the CRU system automatically uploads the treatment information into the specific case file and issues an invoice automatically to the insurance company.
No. 9 (ID 5): CELINA, Customs Declaration Systems, Poland CELINA is the online customs declaration system in Poland. It has originally been designed to serve as customs declaration entry system that would enable traders to submit declarations in electronic form instead of paper and thus eliminate manual keying in of data. By the use of Celina system, businesses have the possibility to submit custom declaration in full and simplified form by Internet in case of export, import and transit. Generally, a declaration consists of one file. The files are produced in XML format. For each type of declaration a detailed specification of XML format has been developed and published (so called ‘public specification’) so that all software companies are able to update their applications to support the standard. The XML
156
Annex 2: Summaries of Good-Practice Cases
format has also been used for the needs of data transfer to various systems of Polish Customs – the processed declaration may also be transmitted to other systems in XML format. Data entry regarding each declaration has only to be done once and then various records are automatically created based on entry data and circulated to the respective custom offices in need of the declaration. Hence data entry for customers has been simplified and data as well as processes in the public agencies have been standardized.
No. 10 (ID 49): Lomake.fi – Citizen Network Service, Finland Lomake.fi is on form portal common to whole Finnish public administration. The aim is that citizens have one place to start dealing with state and municipal organisations. The citizen network form service was introduced in Finland in 1998. By employing Lomake.fi the Finnish authorities made their central forms available to the citizens and others in need of a particular service. Before its implementation the number of different Word and PDF forms amounted to almost 1,000. Lomake.fi service enables electronic transactions between citizens, companies and organizations and central government and local authorities, their agencies and other relevant organizations. The public administration is taking care of the costs and it is free of charge for users. It can of course also include the payment function if needed in a certain service. The service is also an integrated part of the Finnish public sector service portal suomi.fi. The administration also provides a User’s guide to online public services in Finland, which describes the main principles in the use of online services like the political background, data security and privacy. The lomake.fi service includes electronically submitted web-forms and forms to be printed out and sent by post. The web-forms are filled in, signed electronically when necessary, and sent over the Internet. For a successfully completed transaction, the service provides a receipt which shows the date and time of the dispatch and the data submitted. The number of web-forms is increasing as well the number of the organizations participating as a service provider. The printable forms are in Word and PDF formats, which users can download for printing or fill before the printing. Most of the service can be used without logging. The recipient decides the need and methodology for logging on a case-by-case basis. Logging and the signing of forms are done with an electronic identity card (FINEID card) or with Internet banking codes. Lomake.fi portal is maintained by a private company Elma Ltd, which is also responsible for the scalability.
Annex 2: Summaries of Good-Practice Cases
157
No. 11 (ID 87): eInvoicing, Denmark As of 1 February, 2005, all public institutions in Denmark were required to accept invoices from suppliers only in electronic format. By definition, an electronic invoice is a bill converted to a particular format which can be read directly by the public sector’s accounting systems. This particular format is called an “OIOXML electronic invoice” and is based on the OASIS (Organization for the Advancement of Structured Information Standards – see http://www.oasis-open.org) standard Universal Business Language (UBL). Thus, all public-sector entities have been required to convert all systems and administrative processes from physical to digital handling of invoices, credit notes, and other transactions. This reform affects approximately 15 million invoices a year and applies to the entire public sector, from government ministries to nursery schools. Electronic invoicing requires a transportation system, which in the Danish case is based on an existing VANS (Value Added Network Services) Network. Routing of messages from the originator to the receiver requires an electronic postal address. Different identifiers of the address can be used, i.e., a tax registration number, or as in the Danish case an EAN (Electronic Article Number) location number (EAN location numbers are also referred to as Global Location Numbers or GLN’s – see http://www.gs1.org). This number makes possible the unique and unambiguous identification of physical locations and legal entities. Suppliers who cannot or do not wish to submit electronic invoices can still send them in paper format, with the EAN location number, to a so-called “Read-In” bureau, which converts them to digital format and forwards them to the correct public institution in question.
No. 12 (ID 9): Certificate of Residence, Austria The certificate of residence is an application which is accessed via HELP, Austria’s central electronic interface between public administrations and civil society. A certificate of residence is required by many institutions like social insurances, schools, universities, insurance companies, etc. as a proof of regular residence. The online service offers its full electronic transaction. It offers choice between user identification/authentication via electronic signature on smartcard (“Concept Citizen Card”) and via a mobile phone-based option (“Citizen Card Light”), requires access to the central register of residence or population register (ZMR: Zentrales Melderegister), and includes online payment of charges and secure electronic delivery. The service represents the first practical implementation of standardized software modules and specifications developed by the CIO (Chief Information Office), department ‘Technology & Standards’ of the ICT Staff Unit of the Federal Chancellery. Before the reorganization of the registration, citizens had to register with local police authorities using three registration forms. Since the establishment
158
Annex 2: Summaries of Good-Practice Cases
of a central register of residence, only one paper form is issued at change of residence, and certificates of residence need to be applied for at municipal registry offices whenever required, either in person or online. Such certificates are frequently demanded by citizens because they are required for many applications at social insurances as well as educational institutions.
No. 13 (ID 31): Mobile Government Infrastructure, Malta Mobile Government Infrastructure is a service that enables mobile phone users to access a number of government services and receive notifications and information via their mobile phones. Several citizen and business services can be accessed by only using the mobile appliance, e.g. notification of acknowledgements and status change from the Customer Care System available on a number of government services, notifications to ´licenses holders via SMS for the renewal of their licenses, notification of examination results, notification of court case deferrals to lawyers, and many more. A series of common numbers have been established for use by the m-Government services by the Malta Communication Authority in agreement with the (at that time) two Mobile Operators in Malta.
No. 14 (ID 67): ESD – Electronic Service Delivery Toolkit, UK The Electronic Service Delivery toolkit (ESD) provides a way of benchmarking, planning and tracking the development of bringing local authority services on the Internet. Esd-toolkit is about local government community working collaboratively to transform citizen services. The toolkit provides a core list of services that can customized by councils. With esd-toolkit you can e.g. set up your own customized dashboard to give easy access to information (My Toolkit), in the “Projects Database” you will find out what others have achieved, the “Toolkit Local Communities” (TLCs) will let you discuss how others have done it, in the “Document Warehouse”, a document can be loaded into esd-toolkit to make it available across your own council aligned with a service. There are also documents from other authorities which can be repurposed saving a lot of time and duplicated effort. “People Finder” will help you find an expert in a particular area, etc. Many more generic information, methodologies and peer-to-peer networking for the local government community are provided by esd-toolkit. Esd-toolkit has been developed for local authorities by local authorities, optimizing existing work, enhancing and collaborating with national and local projects and undertaking original work where a need was recognized but a solution was not available. Hence, esd-toolkit facilitates standardized approaches to e-government and the exchange of best practice in UK.
Annex 2: Summaries of Good-Practice Cases
159
No. 15 (ID 89): ELAK im BUND, Austria “ELAK im BUND” is part of the overall e-government project in Austria, which aims on general improvement of federal services. The project “ELAK im BUND” of the Federal Chancellery of Austria was started in 2001 and substitutes the paper records through an electronic system. Processes of the administration are managed by a workflow system instead of carrier services. Since 2005 the central administration of all Federal Ministries of Austria (about 8,500 users) produce only electronic files and records. The original records and files “on paper” no longer exist. In the year 2001 the Federal Ministries decided to implement a central ELAK system (electronic file system) for all users in the central administration. Existing ELAK Systems – for example in the Federal Chancellery and the Ministry for Foreign Affairs – have been replaced by a consolidated solution. The ELAK System offers several advantages for citizens and improves the services of government: (1) Written requests can be answered more rapidly, because ELAK generally shortens internal processing in the back office. (2) Detailed information about records is readily available, as ELAK allows quick access to files and efficient investigation. (3) Documents can be transmitted to citizens not only per mail, but also by e-mail, electronic fax and electronic delivery service as well. (4) Processing in the back office can be new organized, because with the workflow component of the ELAK system it is possible to design procedures in parallel. Since its implementation electronic files have been representing the original and only valid records. So the internal room for archives is not necessary any more, the records are stored in the electronic system. A further advantage is that with the ELAK System records are available independently of time and place and the implementation of ELAK has an overall positive impact on administration’s efficiency. Since managers can directly access state information, a controlling instrument exists.
No. 16 (ID 100): HamburgGateway, Germany The HamburgGateway is an e-government infrastructure that provides a single point of contact for online services to all customers. Online services added to legacy applications enable communication and data exchange among them via the HamburgGateway. All services offered online are accessible through a single account. As a city and state, Hamburg provides a wide range of services for different customers, i.e., citizens, business and administration, and employees. For most administrative tasks, existing IT applications are already in place. However, Hamburg’s goal was to offer services online to its customers while using the existing legacy applications. With HamburgGateway, an infrastructure has been created that serves as an access point for all customers to all online services of the city and the state of Hamburg. With its strong two-level authentication, it ensures privacy and security for the customer. At the same time HamburgGateway offers
160
Annex 2: Summaries of Good-Practice Cases
the security required for the application and the overall network of the Hamburg Government. As the diffusion of qualified digital signatures generally is very low and their use is very rare among the majority of potential customers, HamburgGateway allows for a peculiar authentication type in cases where legally binding and secure online transactions in the charge of the city and state of Hamburg are concerned. For those e-services that require authentication of the applicant’s identity, authentication through one-time registration (requiring once the presentation of the identity card at the respective public authority) has been implemented. To allow for this, the legal act was amended by the State Parliament.
No. 17 (ID 151): eInvoicing in Finland: The Region of South Karelia E-invoicing has a long tradition in Finland and has led to many different e-invoice “standards” and providers in the past. The Ministry of Finance set a new direction for standardization in the public sector in 2003, when it made an electronic invoicing recommendation for public authorities. It was decided that the public administration would not develop any new formats or services, but would utilize existing services and formats from the private sector. Two formats were recommended to public authorities as part of this decision: “Finvoice” or “eInvoice”, which have since become important standards in the Finnish business world. A company or public authority can now send an electronic invoice in its preferred format to any other company or public authority, contacting only the service provider it has chosen. The recipient, in turn, can receive electronic invoices in its preferred format, contacting only its service provider. A technical infrastructure shared among service providers allows, besides necessary format conversions, “roaming” of the electronic invoices between service providers. Roaming is a service offered by the messaging network, which allows a sender to send a message seamlessly and reliably to a recipient with a different service provider (and possibly in a different message format by contacting only his own service provider). To enable conversion and roaming, a common electronic address register for all parties, a common conversion table between different formats, and a common testing service have been implemented. The region of South Karelia has been one of the main drivers in the testing and implementation of electronic invoice in local administration from the beginning, and has already felt the impact.
No. 18 (ID 12): My Student Fund (“My-SU”), Denmark SU-Agency (SU ¼ Statens Uddannelsesstøtte: State Education Fund) is the Danish agency responsible for the administration of student grants in Denmark. All students studying approved courses at approved educational institutions in Denmark
Annex 2: Summaries of Good-Practice Cases
161
can apply for financial support from the Danish government. This support can take the form of grants and/or loans, applied for at the educational institution where the student wishes to study. The educational institution checks whether the student application is valid (in terms of whether they are qualified and the course they are applying for entitles them to support) and passes their application (or query if they are already registered) to the SU-Agency. The SU-Agency cooperates with the Danish tax authorities to check tax rates and income, and then replies to the educational institution which in turn provides the information to the student. The authentication of users and of data input to the mainframe system via “My-SU” is undertaken by a public-key developed by KMD (Kommunedata). This is not the same as a digital signature, but very similar. KMD have developed many service systems for the public sector and many of these use the KMD public key as a means of identification (together with the student’s civil registration number). Thus, this KMD public key can be used as authentication of users in many different public systems, but it is not a digital signature as there are some specific legal restrictions, for instance it is not possible to apply for a loan fully on-line as this requires a physical signature.
No. 19 (ID 124): CFENet: Centre for Company Formalities on the Net, France The CFENet (Centres de Formalite´s des Entreprises) is a platform for companies. Via CFENET companies can apply for legally required declarations fully online. Declarations concern e.g. the founding of enterprises, modifications to their situation or the suspension of activity. The Internet platform was created to save time, to provide for a more reliable way of processing data and hence to finally improve the quality of the service provision. Putting the service online aimed to achieve two principal goals: (1) give companies easier access to declarations and (2) simplify administrative procedures. The main target groups are company founders and managers who have to provide a statement about a change of situation. Other target groups or beneficiaries include professionals required to deal with administrative formalities (solicitors, consulting cabinets. . .).
No. 20 (ID 135): Standardized e-Form Exchange via EDIAKT II, Austria In order to be able to spread “communication without a media-break” to all administrative units in Austria, the structure of an electronic file called “EDIAKT II” has been developed and its first version released in June 2005. This standard for
162
Annex 2: Summaries of Good-Practice Cases
electronic file exchange will be usable on all governmental levels (local, regional, national) as well as on the customer side (business and citizen) and will be refined regularly. EDIAKT II is an XML scheme which describes electronic files, including their internal structure and general attributes. EDIAKT II serves for the exchange of electronic files, business cases, and business processes among all Austrian office information systems (KIS) and electronic files systems (ELAK) and will be the standard for long-term archiving. Moreover, a standardized view of all electronic files on the level of the federation, states, municipalities, and communities will be provided to all organizational units even without a KIS or ELAK system. EDIAKT II is the next version of EDIAKT I, which is the standard for the exchange of electronic files among authorities on the federal level in Austria, and to businesses for services on this level. This standard is already fully implemented and working together with ELAK, which serves as a centralized document and workflow management tool for all federal authorities. EDIAKT II will supplement these electronic workflows on the federal level with further definitions for communications with local and regional authorities and its customers. The creation and exchange of electronic files in the EDIAKT II format does not require any specific hardware and software infrastructure, and thus is especially affordable for small municipalities. For local and regional authorities, a specific “Creator” tool of EDIAKT II messages on an open source basis is currently under development using Java technology. Also in Java on an open source basis, a specific “Viewer”, which enables users to display EDIAKT II messages s in a structured and comfortable way and to check electronic signatures, is currently under development. With this viewer, businesses and citizens will be able to receive, select and extract the EDIAKT II messages and to process them with their locally available software tools (e.g. MS-Word, Acrobat Reader).
No. 21 (ID 142): The Danish OIO-XML Project Denmark has adopted XML as a key to information architecture in support of e-government. The philosophy of the Danish e-government strategy is based on government-wide cooperation and reuse, and cooperation with both the private sector and a wider international community. Furthermore, OIO (Open public Information Online) has been established as a “brand” for the Danish e-government initiatives, which are based on creating a national standardization approach to IT architecture and information exchange. This exchange focuses on creating results of value to the citizens and private businesses within the public sector. OIO-XML denotes the Danish use of XML with OIO, which has been standardized to ensure smooth information exchange between public authorities and with citizens and private businesses. The Danish OIO-XML project focuses on coordinating and supporting the development and standardization of OIO-XML interfaces and vocabularies.
Annex 2: Summaries of Good-Practice Cases
163
A national OIO Data Standardization Committee is responsible for ensuring coherence and momentum in the standardization of XML-based interfaces and vocabularies. This committee foresees the development of XML standards in the Danish public sector. The underlying vision is that the public sector must act as one enterprise with coordinated service development and reuse. The benefit is that ultimately, citizens and companies will not have to supply the public sector with the same information twice. Furthermore, wherever it is done effectively, data is collected only once and then maintained. Also the standardization approach aims to easy to identify what kind of standardized data is available and its relevance for a given usage, and the conditions for using them. Finally, it is a principle that data required for good administration practices should be available on all levels on conditions that do not prohibit intensive usage. In 2003, The Danish Ministry of Science, Technology and Innovation published a so-called “White Book” on Enterprise Architecture, which as a general principle recommends a service-oriented architecture model in which IT solutions are designed in a modular fashion, divided into services with well-defined mutual interfaces and, as far as possible, interface with existing public sector IT systems.
No. 22 (ID 15): Crime Declaration on the Internet, Finland Electronic Crime Report is the first results of the web-service development strategy of the Finnish police. The service is based on the common standards of the lomake. fi service (see No. 10 above). The Electronic Crime Report in Internet is for use in situations where there is no need for immediate emergency services or investigations on the place of the crime. It can also not be used if the location (municipality) of the crime is unknown or the crime has been made abroad. Beside the traditional manual crime declaration form citizens can give the needed information using the XML-based electronic form including the information about the municipality, where the crime took place and the claims and requests of the user. User benefits most of the service because they can make declaration where and when ever they want and get the response by mail, fax or pick up it personally at the local police office. Police can balance workload of their officers and has got better quality in the declarations. When user has filled and sent the form it will first processed by the lomake.fi portal and after that sent to the XML-server of the Finnish Policy. After having recognized the location of the crime, the information is sent to the Electronic Crime Report box of the local police office in question. Local police can transfer some parts of the information to their own operational system. The information received by police is used for other services, e.g. in case of a stolen mobile phone police informs the operators to prevent the use of this phone with other SIM-cards.
164
Annex 2: Summaries of Good-Practice Cases
No. 23 (ID 34): LETS – Leeds Electronic Tendering System, UK Leeds Electronic Tendering System (LETS) is the electronic tendering system developed by Leeds City Council in conjunction with the State Government of Western Australia. The system enables the performance of tendering functions such as purchase and supply in an electronic environment. It is the extension of the existing tendering process. LETS is a web based open system and anyone with access to the Internet and an email address and can use the system.
No. 24 (ID 8): HELP – Virtual Guide to Austrian Authorities and Institutions The portal http://www.help.gv.at is designed as Austria’s central electronic interface between public administrations and civil society. It embraces four sub-portals, dedicated to key target groups: citizens, businesses, handicapped people and foreign citizens. Each of these sub-portals is structured according to typical life events and offers access to a large number of information, communication and transaction services spanning across all levels of administration. A further characteristic is that on each life event a set of useful core information is offered in a standard format (e.g. on procedures, required documents, responsible agency, etc.), as well as links to the relevant public administration bodies and forms for download. As such, “HELP” serves as a hub which advises and channels users in each of these life events to the competent authority and online services. “HELP” offers significantly improved user-oriented guidance in administrative contacts to citizens as well as businesses, facilitates and simplifies them, and allows for faster and more flexible delivery of an increasing range of administrative services, especially where they include full online transactions. Run by the Federal Chancellery, the portal is a front-end that integrates services provided at national, i.e. federal level, provincial state level, district authorities at regional level and municipalities at local level. These can be accessed via their own URLs as well. Among others, “HELP” includes the “certificate of residence” as one of the most advanced transaction services provided at national level (see case no 12 above).
No. 25 (ID 150): eID, Estonia Estonia has implemented the ID card as the primary document for identifying citizens and alien residents living within the country. Before the introduction of this card, no national personal identification document – physical or electronic – existed in Estonia. The card, besides serving as a physical identification document, has
Annex 2: Summaries of Good-Practice Cases
165
advanced electronic functions that facilitate secure authentication and a legally binding digital signature, in connection with nationwide online services. There is only one version of the national ID card; no optional features or variations exist. All cards are equipped with a chip containing electronic data and a pair of unique digital certificates relating to each individual. The Estonian ID card scheme is the overall responsibility of the Estonian Government’s Citizen and Migration Board (CMB), and is regulated by the government’s National Identity Act. The process itself is managed through a tight public and private partnership with two key private organizations, the AS Sertifitseerimiskeskus, which is a joint venture between banks and telecommunications € Baltic AS, organizations in Finland, acting as Certification Centre; and TRUB which is the company that personalizes both the physical and electronic aspects of the card.
No. 26 (ID 84): My Gardabaer, an Integrated Citizen Portal and Municipal Case Management System, Iceland My Gardabaer is a unique citizen portal in Gardabaer Municipality, Iceland, which integrates directly with the municipal back-office work processes to provide a real end-to-end e-government solution to citizens. The solution integrates the three major dimensions of efficient e-governance – effective information provision, interactive services, and tools for democratic participation in decision-making processes – seamlessly with back-office processes. The portal is based on the central idea of interactive, transparent, and accountable case management. The municipality is conceived as a co-worker, and citizens have the means to collaborate and actively participate in decision-making regarding their immediate environment and general municipal issues, utilizing an easy and intuitive online environment. With this solution, the citizens of Gardabaer have a one-stop portal for all their dealings with the municipality offices where they can request information and services, and get access to a complete history of the handling and status of their case within the municipality. They can participate in democratic activities, surveys, and consultations made available online to all citizens or to demographically selected target groups based on street, gender, age, etc. The citizen as well as the administration can initiate consultation processes. With the provision of end-to-end case management, it is ensured that the service doesn’t stop at the portal itself, but is fully integrated with the work procedures at the municipal offices. This process is transparent to the citizens and municipal workers and traceable within the same system that the municipal worker uses for daily chores. Responsibilities and specific review processes can be defined within the system to ensure consistent case handling compliant with standard work procedures and legislation. These work processes can be monitored in real time
166
Annex 2: Summaries of Good-Practice Cases
by the management with complete statistical reports provided by the system, enabling a constant control of the quality of service. All the adult inhabitants of the municipality are automatically registered with the system’s CRM module and can access it securely with a unique identifier and password. They can manage their own profile within the system by, e.g., selecting particular interests for receiving selected information and participation in general consultation processes within their area of interest.
No. 27 (ID 98): E-file Including E-signature: Land Acquisition by Foreigners, Austria The objective of this project was to provide customers in the process of obtaining permission for land acquisition in Vienna with the option to handle all stages of the procedure online. This is particularly important as this is a service specifically intended for foreigners living abroad. Generally they can’t haunt local offices, and this application greatly improves the service provision. For the service, new software had to be developed and implemented. This software had to take into consideration the Austrian wide approach to standardize access to public services and files in general. This standardization approach enables the controlled handling of the service among the various involved bodies. Moreover, within this service, it is possible to trace the status of the application (e.g., already gathered feedback) at any time by the public authority as well as by the applicant. On 10 May, 2005, the first permission for land acquisition was granted to an applicant d. This included the first valid e-signature (Amtssignatur, }20 E-government act) put on an e-document in Austria. Additional measurements were taken to provide secure e-payment (Bezahlservice). The department does not deal with e-signature and e-payment themselves, but have them “outsourced” to departments specifically dealing with these issues. As a result, applications are now processed in approximately 1 week instead of the 6–9 months it took previously.
No. 28 (ID 106): Interoperability Platform for the Integral and Multi-Channel Citizen Service System of the Regional Government of Valencia, Spain The Regional Government of Valencia is setting up and testing a clearinghouse infrastructure, an IOP platform, to guarantee the seamless exchange of information both between different departments of the Regional Government, and between the Regional Government and other public organizations that operate in the region
Annex 2: Summaries of Good-Practice Cases
167
(state and local governments, business associations, etc.). The IOP platform offers different levels of integration services depending on the complexity of these services (data, application, and business process integration services, and composite and support services) at a central stage. For this purpose, the IOP platform is composed of a set of functional modules to route the service request, adapt the data format between organizations, and guarantee the security and integrity of the exchanged data. The main resources enabling the seamless and secure exchange of data between the organizations connected to the IOP platform are the corporate network and the Public Key Infrastructure of the Regional Government, as well as the IOP platform technologies themselves.
No. 29 (ID 110): Federal Education Assistance, Germany The Federal Education Assistance programme (BAf€oG) is a public service about financial support of students and pupils. Students and pupils can apply for funding depending on their individual situation such as income, income of parents, legal status, age. Around 750,000 BAf€ oG beneficiaries in Germany fill out their applications (several individual forms) manually each year and submit these to the BAf€oG office responsible. The offices transfer this data into their electronic dialogue system for processing, if they have one. The aim of BAf€ oG eAntrag/BAf€ oG21 is to optimize the BAf€oG application process through online application. For this purpose, two functional areas have been described: the XBAf€oG electronic exchange format (based on OSCI Transport, an XML-based telecommunications protocol that enables trusted communication for e-government applications – OSCI Transport is a standard by law) and the eBAf€oG electronic application. eBAf€ oG was successfully launched mid-2007, followed by a stepby-step implementation of the IT systems in the various federal states of Germany (“L€ander”) then processing applications based on XBAf€oG. XBAf€oG describes an open communication standard on an XML basis. It allows the electronic exchange of BAf€ oG information. Data from online applications can be passed on electronically to clerical processing. In the future it will be possible for all stored BAf€oG data to be passed on across state (“L€ander”) borders in the form of an electronic file (e.g. when a student moves from one state (“Land”) to another within Germany). With eBAf€oG, students can apply for BAf€ oG support for their studies via the Internet. As a result, burdensome public errands are no longer necessary, and the quality of the applications is considerably improved by the dialogue support offered. With follow-up applications (over 80% of all applications are follow-up applications as students can apply annually for funding of the upcoming year), applying is made easier as information that has already been stored in the previous year can be accessed.
168
Annex 2: Summaries of Good-Practice Cases
No. 30 (ID 120): Universities and Colleges Admission Service, Norway Most applications for undergraduate studies at public institutions of higher education in Norway are processed by a centralized application processing center called the Universities and Colleges Admission Service (UCAS). UCAS coordinates the admission to undergraduate level studies at all universities, university colleges, state colleges, and some private colleges in Norway. This comes out to around 95,000 applicants to 47 institutions or 1,166 different courses annually. UCAS also provides advice and information on higher education for the college and university sector. The admission process is as follows: Applicants send one application form to UCAS, containing the names of a maximum of ten different courses, in order of priority. The forms are registered digitally via an optical registration system. UCAS then appoints institutions to evaluate each applicant. In a letter, applicants are asked to forward all relevant documents to these institutions. If the applicant has applied for courses at different institutions with similar admission requirements, one institution will do the evaluation on behalf of the others. The institutions evaluate all applicants and send the results to UCAS, via the Internet. Then incoming data are dealt with electronically, and letters to the applicants are sent offering a maximum of one study entry. This will normally be the highest ranked study on the application form where entry requirements are met by the applicant. The applicant is obliged to return the letter to UCAS, indicating whether or not he/she accepts the offer. If, based on these answers, an institution decides that the number of entry offers for a course has not filled the number of places available, students may be recruited from waiting lists.
No. 31 (ID 138): Kadaster On-line: Direct Access to Land-Registry Products via Internet, the Netherlands Kadaster is the central organization in The Netherlands obliged with cadastral (landed property) issues. Kadaster compiles data about registered properties and records this in public registers and cadastral maps. By making this information available to the public, Kadaster provides clarity about the ownership and other characteristics of registered properties. This promotes legal certainty in transactions involving registered properties. Kadaster on-line, as the name implies, offers these services online to its customers by providing access to various databases; among others, 30 contain administrative cadastral data and 15 contain cartographic cadastral data. These databases are spread over 18 computers and different regional Kadaster offices. Notaries, real estate agencies, local councils, and construction companies now have greater convenience and accessibility to cadastral products all
Annex 2: Summaries of Good-Practice Cases
169
over the Netherlands. Every day more than 60,000 products are provided via Kadaster-on-line, equating to 99.9% of all products provided by Kadaster (0.01% of products are provided offline); about 95% of all Kadaster products for private individuals are provided by Kadaster on-line products.
No. 32 (ID 140): Regional Integrated Health Services for Continuity in Medical Treatment, Friuli Venetia Giulia, Italy The Regional integrated health services for continuity in medical treatment in Friuli Venetia Giulia (SISRCR) are creating an integrated system for the Regional Agency for Health and the Agencies for Health Services of the region. Back-office and front-end systems allow for managing and distributing health services to citizens and specialized consumers (doctors, health operators) thanks to: – A system of portals – one for each agency as well as a joint portal – A call center service for constant access to the services – A smart card system to access the system and to predispose and distribute the pharmaceutical prescriptions and the medical authorizations. Hence the service supplies the citizens with a complete health services system, focused first of all on the de-localization of the access and information points in order to avoid unnecessary energy spent gathering medical reports and information. A special feature, particularly useful for health agencies and general practitioners, is the introduction of a central database containing the medical records of patients. This replaces the previous method of storing them in a decentralized fashion at various general practitioners’ offices, hospitals, and other authorities/agencies concerned with medical treatment.
No. 33 (ID 146): E-Bourgogne: Regional Shared e-government in the Region of Burgundy; The example of the regional shared eProcurement platform, France “E-Bourgogne” is a platform providing e-government services within the region of Burgundy, France. The regional authority as well as communes within the region can offer their services via the platform. The first developed and operational service is the e-procurement service (PROCURE). The aim of e-Bourgogne was and still is it to bring together all public entities within the Burgundy region for their public procurement duties, and to give companies, especially small ones, a single entry to all tenders. Another service for companies, available online since January 2006, is the single entry for enterprises applying for public financial support; since the end
170
Annex 2: Summaries of Good-Practice Cases
of 2006, it has offered the secure transmission of documents from local entities to the central government. The PROCURE service is an online platform providing complete access to all regional public tenders to legal and private entities. The service specifically targets small and medium enterprises with enabling tools that simplify and reduce the cost of submittal. The service was (and still is) organized through a specific governance model, a holding of all public entities at that time unique in France: Groupement d’inte´reˆt public (GIP).
No. 34 (ID 147): ICAR: A System for e-Enabled Cooperation among Public Administrations, Italy ICAR (Interoperabilita` e Cooperazione Applicativa tra le Regioni e le Province Autonome) is setting up and testing the shared technical infrastructure for applications cooperation among Italian regional authorities, following the national standards defined for development of the so-called Public Connectivity and Cooperation System (SPC). The SPC model is that of a “light service oriented architecture (SOA)” based on three pillars: (1) formalization of service agreements, which makes it possible to define not only interfaces but also behaviors, service level agreements (SLAs), security requirements, and linkages with domain ontologies; (2) definition of a federated identity and access management system; (3) definition of metadata (the object of cooperation), semantics, and domain ontologies. Currently, administrations manage and exchange digital information organized and formatted in many different ways, leading to slow information transfer and huge needs for data control and corrections, additional costs for the public administration, and (unnecessary) requests to citizens and companies to provide their data again and again to public offices. ICAR aims to overcome these difficulties. ICAR’s specific objectives are being approached through ten different sub-projects; three infrastructural projects and seven business application projects.
No. 35 (ID 149): The Finnish Address System The Finnish Address System is a central population information system containing many aspects of citizens’ addresses such as names, place of residence but also geographic details. The Finnish municipalities have always been responsible for the address system of the municipality. Nowadays these municipality address systems are the base for all national address databases. The Population Register Centre (PRC) maintains these databases in its population information system. As the
Annex 2: Summaries of Good-Practice Cases
171
municipalities update the central register at the PRC with the uniform address code, no format conversions between local and central systems (concerning, e.g., different address syntax) have to take place. A unique address system for the whole country is today the base for many administrations and e-service processes. Links to several databases such as the Finnish Post, the National Land Survey, and other state registers are already implemented and will be further integrated in the unique address system. This also allows qualitative address data such as secondary residences, integration with topographic data, or information on roads. The PRC, together with the Police Organization, is responsible for the electronic identification of both citizens and civil servants. The Finnish EID-card is based on the population register system and relies on the validity and reliability of the data stored there, including names, personal identification numbers, and addresses of residence. From the residents address a particular address is being built. These address (codes) are already key and will only become more important as a link in many web services serving not only the public and business sector, but also citizens.
No. 36 (ID 154): Social Insurance Code of Reimbursement, Austria The Main Association of Austrian Social Insurance Institutions is the umbrella organization for all Austrian social insurance institutions. Among other things, it is responsible for publishing the so-called “Code of Reimbursement”, a list of all medicinal products which are authorized for marketing in Austria or the EU, of which there is a guaranteed supply, and which are reimbursable. In order to keep this list up to date as regards scientific findings and practical experience, there must be ongoing regular exchange of information between senior clerks and specialized departments of the Main Association, consultants and representatives of the pharmaceutical industry, and members of an independent Drug Evaluation Committee. New legal provisions introduced in 2004 made it necessary to amend procedures and communication processes for drawing up and monitoring the list. Communication that had previously been mainly analogue was to take place as of day X solely via the Web portal for Austrian Social Insurance (www.sozialversicherung.at). This meant that internal and external cooperative procedures had to be realigned. The Main Association saw itself faced with technical, communicative, strategic, organizational, and social challenges. It reacted unilaterally by setting up a team of experts from various disciplines to establish an electronic workflow system. This system now integrates the interests of heterogeneous partners and requirements and diverse technical systems for the purpose of an optimal interface management.
.
Annex 3.1: Ranking of Cases According to Number of Layers Covered
ID 3 5 6 8 9 10 11 14 17 21 22 23 24 26 29 30 32 33 36 37 39 43 45 60 63 77 79 85
Name of case Dossier Medical d’Urgence en PICardie Customs declaration systems Integrated system of polish national registries HELP – virtual guide to Austrian authorities and institutions Certificate of residence PAWA – Paperless import administration Belgian social security benefits for citizens Netborger.dk TYVI service and environmental pollution announcements E-oikonomia web portal e-Enabled child benefit service Auto e-Counter InfoCamere – registration of a new company Citizen income tax The e-government portal of Salzburg country Carta d’Identit Elettronica – electronic ID card in Parma FEDICT – Federal portal for citizens and business SOMCET-Net – transport optimization for eBusiness Digital cartography – OUT OF THE BOX South Tyrol Primar stavanger, electronic navigation for sea transport CAT365 Citizens’ portal eJPA – eJustice point of access Sistema di TRAnsito Doganale Automatizzato Applications for interoperable digital administration Tax information between public administrations, Agencia Tributaria, Departamento de Informatica Tributaria Sheffield public data web Bremen online services The road traffic accident automation project in UK
Layers
Faults
Tec 1 1 1 1
Syn 1 1 1 1
Sem 1 1 1 1
BusP 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1
1 1 1
1 1 1
1 1 1 (continued) 173
174
ID
Annex 3.1: Ranking of Cases According to Number of Layers Covered
Name of case
Layers
Faults
Tec Syn Sem BusP 96 106 117 119 129 131 133 136 138 140 146
147 25 35 38 44 64 84 87 93 110 113 120 127 130 135 139 142 149 150 151 154 1 7 12 13
Central register of residence GENERALITAT EN RED (Generalitat online) The public services broker (www.reach.i.e.) The corporate data repository project DWP’s real-time pension forecasting The integration platform Gemeente Pragmatika Civil registration in German regions – the example of lower Saxony Kadaster-on-line. Direct access to land-registry products via Internet in The Netherlands Regional integrated health services for the continuity in the medical treatment in Friuli Venezia Giulia e-Bourgogne – Regional shared e-government. The example of the eProcurement Platform in Burgundy/France System for e-Enabled cooperation among regional, local and national administrations in Italy Dutch centre for vehicle technology and information (RDW) ETHICS – Electronic Tendering, National Procurement Ltd. (SKI) The Geneva internet voting application Utilities project Accessible and personalised local authority websites My Gardabaer – an integrated citizen portal and municipal case management system Electronic invoicing in Denmark Starter-center Karlsruhe Federal education assistance Individual entrepreneur certificate system (EVIG) Universities and colleges admission service AX – Single window solution for eApplication for export refunds and eExport-declaration Street works information Standardized e-Form exchange via EDIAKT II in Austria Company registration eService in Sweden The Danish OIO-XML project The finnish address system eID in Estonia eInvoicing in Finland – the example of the region of South Karelia Social code of Re-imbursement Management of school transportation in the walloon region InfoVille 21 My Student Fund (“My-SU”) Bibliotek.dk
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 1 1 1
1 1 1 1
1 1 1 1
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1 1 1 1
1 1 1 1 1 1 1
1 1 1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1
(continued)
Annex 3.1: Ranking of Cases According to Number of Layers Covered
ID
Name of case
175
Layers
Faults
Tec Syn Sem BusP 15 20 28 34 94 98 108 124 128 31 67 89 100
Crime declaration on the internet Virtual construction platform The Bavarian Junior Highschool Network LETS – Leeds Electronic Tendering System Electronic gateway for online administrative services in Stara Zagora e-file including e-signature – land acquisition by foreigners Centre of timely intervention system of timely intervention (SVI) CFENet: centre for company formalities on the net F€oretagarguiden (the entrepreneurs guide) Mobile government infrastructure ESD – electronic service delivery toolkit ELAK im BUND Hamburg gateway – the digital gate to the city
1 1 1 1 1
1 1 1 1 1
1 1
1 1
1 1 1 1 1 1
1 1 1 1 1 1
1 1 1 1
2 2 2 2
.
Annex 3.2: Cumulative Structure for Standardization Items
ID
Name of case
3
Dossier medical d’Urgence en PICardie Customs declaration systems Integrated system of polish national registries HELP – virtual guide to Austrian authorities and institutions Certificate of residence PAWA – paperless import administration Belgian social security benefits for citizens Netborger.dk e-Enabled child benefit service Auto e-Counter InfoCamere – registration of a new company Citizen income tax Sistema di TRAnsito Doganale Automatizzato The road traffic accident automation project in UK Starter-center Karlsruhe AX – single window solution for eApplication for export refunds and eExport-declaration DWP’s real-time pension forecasting The integration platform Civil registration in German regions – the example of lower Saxony
5 6 8 9 10 11 14 22 23 24 26 45 85 93 127
129 131 136
Data exchange Data format keys 1 1
Work flow definitions 1
Inconsistent answers 0
1 1
1 1
1 1
0 0
1
1
1
0
1 1
1 1
1 1
0 0
1
1
1
0
1 1 1 1
1 1 1 1
1 1 1 1
0 0 0 0
1 1
1 1
1 1
0 0
1
1
1
0
1 1
1 1
1 1
0 0
1 1 1
1 1 1
1 1 1
0 0 0 (continued)
177
178
ID
Annex 3.2: Cumulative Structure for Standardization Items
Name of case
138 Kadaster-on-line. Direct access to land-registry products via internet in the Netherlands 140 Regional integrated health services for the continuity in medical treatment in Friuli Venezia Giulia 151 eInvoicing in Finland, region of South Karelia 154 Social code of Re-imbursement 38 The Geneva internet voting application 87 Electronic invoicing in Denmark 110 Federal education assistance 139 Company registration eService in Sweden 12 My student fund (“My-SU”) 13 Bibliotek.dk 124 CFENet: centre for company formalities on the net 15 Crime declaration on the internet Total
Data exchange Data format keys 1 1
Work flow definitions 1
Inconsistent answers 0
1
1
1
0
1
1
1
0
1 1
1 1
1 0
0 0
1 1 1
1 1 1
0 0 0
0 0 0
1 1 1
0 0 0
1 1 1
2 2 2
1 31
0 27
0 26
0 6
References
Alabau A (2005) The European Union and its E-Government Development Policy. Following the Lisbon Strategy Objectives, Published with the support of Vodafone Fundacio´n. http://www. upv.es/~lguijar/socinfo/publicaciones.htm. Accessed 31 May 2011 Archmann S, Kudlacek I (2008) Interoperability and the exchange of good-practice cases. European Journal of ePractice, No 2: new e-ways of doing the Government’s job, February 2008. http://www.epractice.eu/en/document/287899. Accessed 30 May 2011 Benjamin RI, de Long DW, Scott Morton MS (1990) Electronic data interchange: how much competitive advantage? Long Range Plann 23(1 (February)):29–40 Besen SM, Farrell J (1994) Choosing how to compete: strategies and tactics in standardization. J Econ Perspect 8(2):117–131 Blind K, Jungmittag A (2008) The impact of patents and standards on macroeconomic growth: a panel approach covering four countries and 12 sectors. In J of Prod Anal 29:51–60 Bousson A, Keravel A (2005) Organizational and economic effects in networked public organizations: organizational case studies. TERREGOV Project IST 507749. Deliverable D 6.8, 31.12.2005. http://www.egovinterop.net. Accessed 30 May 2011 Cash JI Jr (1985) Interorganizational systems. An information society, opportunity or threat? Inf Soc 3(2):199–228 CEC (2000) – Council of the European Union and Commission of the Euopean Communities: eEurope 2002 – An Information Society of All – Action Plan, Brussels. http://ec.europa.eu/ information_society/eeurope/2002/documents/archiv_eEurope2002/actionplan_en.pdf. Accessed 01 March 2011 CEC (2001) – Commission of the European Communities: Communication from the Commission to the Council and the European Parliament, COM (2001) 140 final – eEurope 2002 – Impact and Priorities, Brussels. http://ec.europa.eu/information_society/eeurope/2002/news_library/ pdf_files/communication_en.pdf. Accessed 30 May 2011 CEC (2001) – Commission of the European Communities, Directorate General Information Society: Web-based Survey on Electronic Public Services. Results of the 1st measurement. Prepared by Cap Gemini Ernst & Young, October 2001. http://ec.europa.eu/information_society/eeurope/ 2002/documents/CGEY%201st%20measurement.pdf. Accessed 30 May 2011 CEC (2002) – Commission of the European Communities: Communication from the Commission to the Council, the European Parliament, the Economic and Social Committee and the Committee of the Regions, COM (2002) 263 final – eEurope 2005 – An information society for all, Brussels. http://ec.europa.eu/information_society/eeurope/2002/news_library/ documents/eeurope2005/eeurope2005_en.pdf. Accessed 30 May 2011 CEC (2003) – Commission of the European Communities: Communication from the Commission to the Council, the European Parliament, the European Economic and Social Committee and the Committee of the Regions, COM(2003) 567 final – The Role of eGovernment for 179
180
References
Europe’s Future, Brussels. http://ec.europa.eu/information_society/eeurope/2005/doc/all_about/ egov_communication_en.pdf. Accessed 30 May 2011 CEC (2005) – Commission of the European Communities, Directorate General for Information and Media: online availability of public services. How is Europe progressing? Web-based survey on electronic public services. Report of the 5th measurement. Prepared by Capgemini, March 2005. http://ec.europa.eu/information_society/eeurope/i2010/docs/online_pub_serv_ 5th_meas_fv4.pdf. Accessed 30 May 2011 CEC (2006) – Commission of the European Communities: Communication form the Commission to the European Parliament, the Council, the European Economic and Social Committee of the Regions – i2010 eGovernment Action Plan: Accelerating eGovernment in Europe for the Benefit of All, COM(2006) 173 final, Brussels. http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri¼COM:2006:0173:FIN:EN:PDF. Accessed 30 May 2011 CEC (2006) – Commission of the European Communities: Communication from the Commission to the Council and the European Parliament COM(2006) 45 – Interoperability for PanEuropean eGovernment Service, Brussels. http://ec.europa.eu/idabc/servlets/Doc7777.pdf? id¼24117. Accessed 30 May 2011 CEC (2010) – Commission of the European Communities: Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions: Towards Interoperability for European Public Services, COM(2010) 744 final (including EIF 2.0), Brussels. http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri¼COM:2010:0744:FIN:EN:PDF. Accessed 30 May 2011 CEC (2010) – Commission of the European Communities: Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions. A Digital Agenda for Europe, COM(2010) 245 final/2, Brussels, 26.8.2010. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri¼CELEX:52010DC0245R (01):EN:NOT. Accessed 01 June 2011 Charalabidis Y (ed) (2011) Interoperability in digital public services and administration. Bridging e-government and e-business. IGI, Hershey Charalabidis Y, Concalves RJ, Popplewell K (2011) Towards a scientific foundation for interoperability. In: Charalabidis Y (ed) Interoperability in digital public services and administration. GI Global, Hershey, pp 355–373 Chatterjee D, Ravichandran T (2004) Inter-organizational information system research: a critical review and an integrative framework. In: Proceedings of the 37th Hawaii international conference on systems science, IEEE, pp 1–10 Child J (1972a) Organization structure and strategies of control: a replication of the Aston study. ASQ 17:163–177 Child J (1972b) Organizational structure, environment and performance: the role of strategic choice. Sociology 6:1–22 Cimander R, Hansen M, Kubicek H (2009) Electronic signatures as obstacle for cross-border EProcurement in Europe – lessons from the PROCURE-project. Published in the library on epractice.eu: http://www.epractice.eu/en/library/292080. Accessed 30 May 2011 Corbett CJ (2006) Global diffusion of ISO 9000 certification through supply chains. Manuf Serv Oper Manag 8(4):330–350 Cyert RM, March JG (1963) A behavioral theory of the firm. Wiley, Englewood Cliffs Damsgaard J, Lyytinen K (1998) Contours of diffusion of electronic data interchange in Finland overcoming technological barriers and collaborating to make it happen. J Strateg Inf Syst 7 (4):275–297 Dawes SS (2003) Understanding new models of collaboration for delivering government service. Commun ACM 46(1):40–42 Dawes SS, Cook ME (2007) Intergovernmental digital governments through G2G relationships and applications. In: Anttiroiko AV, Malkia M (eds) Encyclopedia of digital government, vol I. IDEA Group, Hershey, pp 1114–1119
References
181
Diedrich E, Schmidt D, Wimmer M (2006) A three-dimensional framework to realize interoperability in public administrations. In: Abecker A, Mentzas G, Stojanovic I (eds) Semantic web for eGovernment. Proceedings of the workshop at the 3rd European semantic web conference, 12 June 2006 DODD (1977) DODD 2010.6 Standardization and interoperability of weapon systems and equipment within the North Atlantic Treaty Organization. NATO EC (1991) Council directive 91/250/EC, 14.5.1991 on the legal protection of computer programmes. Official Journal of the European Communities. No L 122, 17.05.91. http://eur-lex.europa.eu/ LexUriServ/LexUriServ.do?uri¼CELEX:31991L0250:EN:HTML. Accessed 01 June 2011 EC (1995) Council decision of 6 November 1995 on a community contribution for telematic interchange of data between administrations in the community (IDA) (95/468/EC). Official Journal of the European Communities. No L 269, 11.11.95. http://eur-lex.europa.eu/smartapi/ cgi/sga_doc?smartapi!celexplus!prod!DocNumber&lg¼en&type_doc¼Decision&an_doc¼ 1995&nu_doc¼468. Accessed 01 June 2011 Eom SB (ed) (2005) Inter-organizational information systems in the Internet age. Idea Group, Hershey EPAN (2004) European public administration network, e-government working group: key principles of an interoperability architecture. Brussels. http://www.epractice.eu/en/library/ 281244. Accessed 31 May 2011 ETSI (2006) European Telecommunications Standards Institute: achieving technical interoperability – the ETSI approach. ETSI white paper No. 3. By Hans van der Veer (Lucent Technologies) and Anthony Wiles (ETSI), October 2006. http://www.etsi.org/website/ document/whitepapers/wp3_iop_final.pdf. Accessed 30 May 2011 EU (1998) Council directive 98/34/EC, 21.7.1998, laying down a procedure for the provision of information in the field of technical standards and regulations and of rules on information society services. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri¼CELEX: 31998L0034:EN:HTML. Accessed 01 June 2011 EU (1999) Decision No 1719/1999/EC of the European Parliament and the of the Council of 12 July 1999 on a series of guidelines, including the identification of projects of common interest, for Trans-European networks for the electronic interchange of data between administrations (IDA). Official Journal of the European Union, L 203/1 of 3.08.1999. http://eur-lex.europa.eu/ LexUriServ/LexUriServ.do?uri¼OJ:L:1999:203:0001:0008:EN:PDF. Accessed 01 June 2011 EU (1999) Decision No 1720/1999/EC of the European Parliament and the of the Council of 12 July 1999 adopting a series of actions and measures in order to ensure interoperability of and access to Trans-European networks for the electronic interchange of data between administrations (IDA). Official Journal of the European Union, L 203 of 3.08.1999. http://eur-lex.europa.eu/ LexUriServ/LexUriServ.do?uri¼OJ:L:1999:203:0009:0013:EN:PDF Accessed 01 June 2011 EU (2004) Decision No 2004/387/EC of the European Parliament and of the Council of 28 April 2004 on interoperable delivery of Pan-European eGovernment services to public administrations, businesses and citizens (IDABC). Official Journal of the European Union, L 181 of 18.05.2004. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri¼OJ:L:2004: 181:0025:0035:EN:PDF. Accessed 01 June 2011 EU (2009) Decision No 922/2009/EC of the European Parliament and of the Council of 16 September 2009 on interoperability solutions for european public administrations (ISA). Official Journal of the European Union, L 260 of 3.10.2009. http://eur-lex.europa.eu/ LexUriServ/LexUriServ.do?uri¼OJ:L:2009:260:0020:0027:EN:PDF. Accessed 01 June 2011 European Communities (2004) European interoperability framework for pan-European e-government services (EIF 1.0). http://ec.europa.eu/idabc/servlets/Docd552.pdf?id¼19529. Accessed 30 May 2011 European Communities (2008) Draft document as basis for EIF 2.0. http://ec.europa.eu/idabc/ servlets/Docb0db.pdf?id¼31597. Accessed 31 May 2011 Gandal N, Shy O (2001) Standardization policy and international trade. J Int Econ 53:363–383
182
References
Gartner (2009) NIFO project – Final report, a report for European commission directorate general for informatics, 05–05 2009, engagement: 222504110, version 130. http://ec.europa.eu/idabc/ servlets/Doc79da.pdf?id¼32120. Accessed 31 May 2011 Genschel P (1995) Standards in der Informationstechnik, Institutioneller Wandel in der internationalen Standardisierung. Campus, Frankfurt/New York Grimm LG, Yarnold PR (1995) Reading and understanding multivariate statistics. American Psychological Association, Washington, DC Guijarro L (2007) Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States. Gov Inf Q 24(1):89–101 Guijarro L (2010) Frameworks for fostering cross-agency interoperability in e-government initiatives. In: Scholl HJ (ed) E-government: information, technology, and transformation, vol 17, Advances in management information systems. M.E. Sharpe, Armonk, pp 280–299 Guttman L (1950) The principal components of scale analysis. In: Stouffer SA, Guttman L, Suchman EA, Lazarsfeld PF, Star SA, Clausen JA (eds) Measurement and prediction. Wiley, New York, pp 312–361 Hagen M (2001) Ein Referenzmodell f€ ur Online-Transaktionssysteme im Electronic Government. Rainer Hampp Verlag, M€ unchen und Mering Hagen M, Kubicek H (eds) (2000) One-stop government in Europe. Results from 11 national surveys. University of Bremen, Bremen Hirst P (2000) Democracy and governance. In: Pierre J (ed) Debating governance: authority, steering, and democracy. Oxford University Press, Oxford Hjort-Madsen K (2006) Enterprise architecture implementation and management. A case study on interoperability. In: Proceedings of the 39th Hawaii international conference on system science, IEEE, pp 1–10 Hjort-Madsen K, Pries-Heje J (2009) Enterprise architectures in government: fad or future? In: Proceedings of the 42nd Hawaii international conference on system science, IEEE Homburg VMF (1999) The political economy of information management. A theoretical and empirical analysis of decision making regarding interorganizational information systems. Groningen: SOMS/Capelle a/d Issel: Labyrint Homburg VMF (2007) Managing information exchange in e-government initiatives. In: Anttiroiko AV, Malkia M (eds) Encyclopedia of digital government, vol I. IDEA Group, Hershey, pp 1185–1189 IDABC (2009) NIFO national interoperability framework observatory overview of the national interoperability frameworks – NIF Overview, Last update: 18 March 2009. http://ec.europa.eu/ idabc/servlets/Doc2d7e.pdf?id¼32124. Accessed 31 May 2011 IDABC (2009) NIFO national interoperability framework observatory analytical model, Last update: 05-May-09. http://ec.europa.eu/idabc/servlets/Doc2d7e.pdf?id¼32124. Accessed 31 May 2011 IEEE (1990) Institute of electrical and electronics engineers, standard computer dictionary. IEEE Press, New York IITF (1993) Information infrastructure task force, national information infrastructure: agenda for action. National Telecommunications and Information Administration, Washington, DC ISO/IEC (1993) ISO/IEC 2382–1:1993 Information Technology – Vocabulary – Part 1: Fundamental Terms, International Organization for Standardization ITGI (2000) IT Governance Institute, COBIT framework, 3rd edition ITGI (2003) IT Governance Institute: board briefing on IT governance. 2nd edition, www.itgi.org. Accessed 18 Aug 2007 Janssen M, Snijders B, Herkemij F (2011) A reference architecture for interoperable and adaptive processes. In: Charalabidis Y (ed) Interoperability in digital public services and administration. IGI Global, Hershey, pp 162–179 Jarillo JC (1995) Strategic networks: creating the borderless organization. ButterworthHeinemann, Oxford Kalil TA (1997) The clinton-gore national information infrastructure initiative. In: Kubicek H, Dutton WH (eds) The social shaping of information super highways. European and American
References
183
Roads to the information society. Campus Verlag/St. Martins Press, Frankfurt/New York, pp 45–59 Kenny DA, Rubin DC (1977) Chance reproducibility in Guttman scaling. Soc Sci Res 6:188–196 Kimberley P (1991) Electronic data interchange. McGraw-Hill, New York Klischewski R (2004) Information integration or process integration: how to achieve interoperability in administration. EGOV 04 at DEXA, Zaragoza, Spain Kubicek H (1992) Informationsverbund, € uberbetrieblicher. In: Frese E (ed) Handw€orterbuch der organisation. Poeschel, Stuttgart, pp 994–1009 Kubicek H (1993) The organizational gap in interbranch EDI systems. EDI Europe 33(2):105–124 Kubicek H, Cimander R (2005) Interoperability in eGovernment – a survey on information needs of different EU stakeholders. Eur Rev of Polit Technol (ERPT) 3:59–74 Kubicek H, Cimander R (2009) Three dimensions of organizational interoperability – insights from recent studies for improving interoperability frameworks. Eur J ePractice 6:3–14. http:// www.epractice.eu/en/document/287924. Accessed 30 May 2011 Kubicek H, Dutton WH (1997) The social shaping of informatin super highways: an introduction. In: Kubicek H, Dutton WH (eds) The social shaping of informatin super highways. European and American roads to the information society. Campus Verlag/St. Martins Press, Frankfurt/ New York, pp 9–44 Kubicek H, Seeger P (1992) The negotiation of data standards. A comparative analysis of EAN and EFT/POS systems. In: Dierkes M, Hoffmann U (eds) Technology at the outset. Social forces in the shaping of technological innovations. Campus, Frankfurt/New York, pp 351–374 Kubicek H, Millard J, Westholm H (2007) Back-office integration for online services between organizations. In: Anttiroiko AV, Malkia M (eds) Encyclopedia of digital government, vol I. IDEA Group, Hershey, pp 123–130 Lampathaki F, Tsiakaliaris C, Stassis A, Charalabidis Y (2011) National interoperability frameworks. The way forward. In: Charalabidis Y (ed) Interoperability in digital public services and administration. IGI Global, Hershey, pp 1–24 Layne K, Lee J (2001) Developing fully functional e-government. A four-stage model. Gov Inf Q 18(2):122–136 Lynn LE Jr, Heinrich CJ, Hill CJ (2000) Studying Governance and Public Management: Challenges and Prospects. J-PART 10(2000):2, 233–261 Mayntz R (2004) Governance im modernen staat. In: Benz A (ed) Governance – Regieren in komplexen Regelsystemen. Eine Einf€ uhrung. Vs Verlag, Wiesbaden, pp 66–75 Meuleman L (2008) Public management and the metagovernance of hierarchies, networks and markets. Physica, Heidelberg Millard J, Iversen JS, Kubicek H, Westholm H, Cimander R (2004) Reorganization of government back-offices for better electronic public services – European good practices (back-office reorganization). Final report to the European Commission, Institute for Information Management Bremen GmbH and Danish Technological Institute. http://www.epractice.eu/en/library/ 281474. Accessed 31 May 2011 Mykk€anen JA, Tuomainen MP (2008) An evaluation and selection framework for interoperability standards. Inf Softw Technol 50:176–197 NIST (1990) U.S. Government Open System Interconnection Profile (GOSIP), Version 2.0 OECD (2003) Organisation for economic co-operation and development: the e-government imperative. OECD, Paris Pardo TA, Burke GB (2008) Improving government interoperability: a capability framework for government managers. Center for Technology in Government, University of Albany, October 2008. http://www.ctg.albany.edu/publications/reports/improving_government_interoperability/improving_government_interoperability.pdf. Accessed 01 June 2011 Pardo TA, Burke GB (2008) Government worth having: a briefing on interoperability for government leaders. Center for Technology in Government, University of Albany. http://www.ctg. albany.edu/publications/reports/government_worth_having/government_worth_having.pdf. Accessed 31 May 2011
184
References
Pardo TA, Burke GB (2009) IT governance capability: laying the foundation for government interoperability. Center for Technology in Government, University of Albany. http://www.ctg. albany.edu/publications/reports/it_gov_capability/it_gov_capability.pdf. Accessed 01 June 2011 Pardo TA, Nam T, Burke GB (2011) E-government interoperability: interaction of policy, management and technology dimensions. Social science computing review, DOS 10.1177/ 0894439310392184. http://ssc.sagepub.com/content/early/2011/01/11/0894439310392184. full.pdf. Accessed 31 May 2011 Peristeras V, Tarabanis K (2006) The connection, communication, consolidation, collaboration interoperability framework (C4IF) for information systems interoperability. International Journal of Interoperability in Business Information Systems (IBIS), 1(1):61–72. http://www. ibis.uni-oldenburg.de/download/issues/01/ibis_01_3.pdf. Accessed 31 May 2011 Perry JL, Rainey HG (1988) The public-private distinction in organization theory: a critique and research strategy. Acad Manag Rev 13(2):182–201 Rainey HG, Backoff RW, Levine CH (1976) Comparing public and private organizations. Public Admin Rev 36:233–244 Reimers K, Johnston R, Klein S (2008) A theorizing evolution of inter-organizational information systems on long timescales. Working papers on information systems, vol 8, Art. 31 Sarkar MB, Butler B, Steinfield C (1995) Intermediaries and cybermediaries: a continuing role for mediating players in the electronic marketplace. Journal of Computer-Mediated Communication, Special issue on electronic commerce, 1(3) Schmidt SK, Werle R (1998) Coordinating technology – studies in the international standardization of telecommunications. MIT Press, Cambridge Scholl HJ (2010) Electronic government: a study domain past its infancy. In: Scholl HJ (ed) E-government: information, technology, and transformation, vol 17, Advances in management information systems. M.E. Sharpe, Armonk, pp 11–30 Scholl HJ, Klischewski R (2007) E-government integration and interoperability: framing the research agenda. Int J Public Admin (IJPA) 30(8–9):889–920 Staab S, Studer R (eds) (2004) Handbook of ontologies. Springer, Berlin/Heidelberg/New York Sydow J (1992) Strategische netzwerke. Evolution und organisation. Gabler, Wiesbaden Tambouris E, Tarabanis K, Peristeras V, Liotas N (2007) Study on interoperability at local and regional level. Prepared for the eGovernment unit, DG information society and media, European commission, Feb. 2007. http://www.epractice.eu/en/library/281708. Accessed 31 May 2011 Thompson JP (1967) Organizations in action. McGraw-Hill, New York Tzelepis D, Trekouras K, Skuras D et al (2006) The effects of ISO 9001 on firms’ productive efficiency. Int J Oper Prod Man 26(9–10):1146–1165 United Nations (2003) Development programme, democratic governance group, public administration practice note, bureau for development policy Van Grembergen W, De Haes S, Guldentops E (2004) Structures, processes and relational mechanisms for information technology governance: theories and practices. In Van Grembergen W (ed.) Strategies for information technology governance. Idea Group Publishing, Hershey http://www. antwerpmanagementschool.be/kennis_onderzoek/kennis_expertisecentra/itag_research_institute/ goto.php?id¼a8f15eda80c50adb0e71943adc8015cf&type¼docs. Accessed 30 May 2011 Weill P, Ross JW (2004) IT governance. How top performers manage IT decision rights for superior results. Harvard Business School Press, Boston Weill P, Ross JW (2005) A matrix approach to designing IT governance. MIT Sloan Manage Rev 46(2):41 Welzel C, Hartenstein H, von Lucke J (2011) Design and standardization of core directories for egovernment. In: Charalabidis Y (ed) Interoperability in digital public services and administration. IGI Global, Hershey, pp 218–237 Woods WA (1975) What’s in a link: foundations for semantic networks. In: Bobrow DG, Collins A (eds) Representation and understanding: studies in cognitive science. Academic, New York, pp 35–82 Zachman JA (1987) A framework for information systems architecture. IBM Syst J 26(3):277–293
Authors
Dr. Herbert Kubicek is professor of Applied Computer Science, in particular telecommunications and information management, at the University of Bremen, and scientific director of the Institute for Information Management Bremen (ifib). He has a background in business administration and social science. His research deals with inter-organizational information systems since the 1990s. Recent studies include a comparative analysis of success criteria and success factors of e-participation (in German) and a comparative analysis of national e-identity management systems in eight European countries. Ralf Cimander is senior researcher at the Institute for Information Management Bremen (ifib). He was involved in the identification, analyses and description of good practice cases in the European Commissions’ Study on Back-office Reorganization and the MODINIS Study on Interoperability in E-Government at Local and Regional Level as well as an European Commissions’ transfer project concerned with interoperability in public procurement. His current research is on the comparative assessment of e-participation in the context of sustainable development and climate change. Dr. Hans J Scholl is an Associate Professor with tenure in the Information School at the University of Washington, Seattle, WA, USA. His special interests include open government, interoperability, emergency and disaster response management, and strategic choices in mobile technology diffusion in digital government. Dr. Scholl is the president of the Digital Government Society and also the vice chair of the IFIP TC 8.5 Working Group (Information Systems and Public Administration). He chairs the renowned Electronic Government Track at the Hawaii International Conference on System Sciences (HICSS) and co-organizes the premier European conference on e-Government (IFIP EGOV).
185
