Egov Report UN

e-Government Interoperability: Guide
GUIDE GU D
United Nations Development Programme with the support of IBM Oracle
The analysis and recommendations of this publication do not necessarily reflect the views of the United Nations Development Programme nor do they necessarily reflect the views of the institutions with which the authors are affiliated.
Copyright 2007 UNDP
United Nations Development Programme Regional Centre in Bangkok 3rd Floor, UN Service Building Rajdamnern Nok Avenue Bangkok 10200,Thailand http://regionalcentrebangkok.undp.or.th
Design and layout: Keen Media (Thailand) Co., Ltd.
ISBN: 978-974-13-1616-8
Foreword
Information and communication technologies (ICTs) provide developing nations with an unprecedented opportunity to meet vital development goals such as poverty alleviation, basic health care improvement and universal education more effectively than before, via the appropriate utilization of technological tools. There is increasing evidence that e-government, if implemented strategically, can improve efficiency, accountability and transparency of government processes. However, the full potential of e-government applications and other ICTs remains to be fully harnessed by developing countries. Through UNDPs experiences in e-government initiatives, one of the key challenges we have identified is the existence of a patchwork of ICT solutions in different government offices that are unable to talk or exchange data. In the process of digitization, government processes and systems are, in many instances, reinforced rather than transformed. As a result, citizens continue to visit different departments to access public services, even after the introduction of ICTs, as systems are not interconnected. Recognizing that e-government should be transformative and become more citizen- rather than governmentfocused in delivering public services, investing in the development of an e-government interoperability framework is fundamental. Otherwise, the millions of dollars spent on e-government would rarely lead to good governance and the achievement of the Millennium Development Goals. UNDP created a Study Group of government officials from 14 nations, supported by a team of experts from IBM, Oracle and the International Open Source Network, to help countries, especially those in the Asia-Pacific region, reverse this trend of fractured ICT projects by developing and promoting Government Interoperability Frameworks (GIFs). Working collaboratively, this group shared and reviewed existing GIFs, promising practices around interoperability and strategies and policies for promoting open standards, resulting in the development of guidelines that are now reflected in a GIF series of three publications. The three publications on e-Government Interoperability (the Overview, the Guide and the Review of GIFs in selected countries) aim to assist countries who are striving to set up or improve interoperable ICT frameworks for better e-government delivery. It is our hope that the series will provide a helping hand a guiding tool to understanding what e-government interoperability is, why it is important and how governments can improve or start to develop GIFs. The idea for the project came to life during a policy dialogue at a regional conference on open standards that the UNDP Asia-Pacific Development Information Programme (APDIP) organized with the National Electronics and Computer Technology Center in Bangkok in 2006. Participants agreed that government policies of interoperability are advantageous and that, if governments have not already done so, they should consider formulating their respective GIFs. In order to ensure that the final publications are responsive to the requirements for interoperability in the respective countries, the GIF Study Group collaborated online and had face-to-face conversations. Hosted by the Chinese Governments State Council Informatization Office, the GIF Study Group met in Beijing on 18-20 April 2007. At the workshop, participants shared experiences, asked questions and set goals for their work. The GIF Study Group includes representatives from the Governments of Brazil, Canada, China, Egypt, India, Indonesia, Malaysia, Netherlands, New Zealand, Philippines, South Africa, Sri Lanka, Thailand and Viet Nam. Also represented are the European Commission and a standards expert from the United States. The study was convened by UNDP and project advisor Dr. Emmanuel C. Lallana, who is also the author of all three publications in the series.
Foreword
iii
This series is a practical guide and attempts to answer questions that policy makers and practitioners may have on GIF and open standards. For ICT and e-government to work for development and poverty alleviation, information and knowledge need to flow seamlessly across agency borders and various levels of government, and ultimately between different countries, across regions and continents without being locked into specific software packages. Eventually, this will lead to better and more informed decisions, better public service and better governance. Please visit our e-Government Interoperability website for additional information: http://www.apdip.net/projects/gif
Elizabeth Fong Regional Manager UNDP Regional Centre in Bangkok
iv
Contents
Foreword UNDP GIF Study Group Members List of Acronyms iii vii viii
1 2 3 4 5 6 7
Introducing the GIF: Benefits of Interoperability for e-Government The GIF: Context Approach and scope Open standards Principles Alignment with national strategies GIF: Technical Content Standard categories Standards selection GIF Development Process GIF development actors Creating the GIF Revising the GIF GIF Implementation and Governance Agency responsibilities Compliance Enforcement Capacity development Metrics Architectural Approaches to Interoperability Defining Enterprise Architecture and Service-Oriented Architecture Objectives Architectural principles Technical content Development and design Implementation and governance Conclusion: Policy, Not Technology, Matters Bibliography
Acknowledgments
1 3
13
19
23
29 31
35
List of Boxes Box 1: Public security through interoperability in Brazil Box 2: SCOSTA - open standards and interoperability in India Box 3: The case of labour insurance in the construction industry in China Box 4: The evolution of UK eGIF List of Tables Table 1: Scope of various GIFs Table 2: Principles of various GIFs Table 3: Interoperability domain/s of various GIFs Table 4: GIF layers Table 5: Standards maturity and obsolescence List of Figures Figure 1: From GIF Version 0 to Version 1 Figure 2: From GIF Version 1 to Version 2
2 5 7 16
3 6 9 10 11
14 15
UNDP GIF Study Group Members

Appreciative of the inclusive publication development process and the careful reviews by the Study Group members listed below, the views expressed in this paper are the views of the authors alone. Convener of Study Group: Emmanuel C. Lallana, UNDP-APDIP GIF Advisor
Brazil Rogerio Santanna, Secretary, Ministry of Planning, Budget and Management Canada Gary Doucet, Executive Director, Architecture, Standards and Engineering, Treasury Board of Canada China Madame Chen Xiaozhu, Director General, State Council Informatization Office Egypt Hatem El Kadi, Program Director, Government Services Development, Ministry of State for Administrative Development European Union Serge Novaretti, Head of Unit, Interoperable Delivery of European eGovernment Services to Public Administrations India B K Gairola, Director General, National Informatics Centre Indonesia Pancat Setyantana, Head of Interoperability Division, Directorate General ICT Application, Ministry of ICT and Communication Malaysia Norhamimah Ibrahim, Deputy Director, ICT Policy & Planning Division, Malaysian Administrative Modernisation & Management Planning Unit
Netherlands Jan Willem Broekema, Manager, National Coordinator Open Standards and Open Source Program New Zealand Laurence Millar, Deputy Commissioner, Information and Communication Technologies, State Services Commission Philippines Maria Teresa Garcia, Chief of Staff, Commission on Information and Communications Technology South Africa Aslam Raffee, Chairperson, Government IT Officers Council, OSS Working Group, Department of Science & Technology Sri Lanka Shahani Markus Weerawarana, Chief Technology Officer, Information and Communication Technology Agency of Sri Lanka Thailand Puttipong Puasiri, Project Leader, e-Government, Ministry of Information and Communication Technology USA Andrew Updegrove, Gesmer Updegrove LLP Viet Nam Nguyen Ai Viet, Deputy Director General, National Steering Committee on ICT and Director of e-Government Architecture and Infrastructure Development Center, Ministry of Posts and Telematics
UNDP GIF Study Group Members
vii
List of Acronyms
APDIP EA EIF EPAN e-PING FEA G2B G2C G2G G2OG G2Org GIF ICT IEEE IP MDG NEA NGO SAGA SCOSTA SOA UNDP VoIP UNDP Asia-Pacific Development Information Programme Enterprise Architecture European Interoperability Framework European Public Administration Network Brazils Government Interoperability Framework US Federal Enterprise Architecture government-to-business government-to-citizens government-to-government government-to-other-governments government-to-organizations Government Interoperability Framework information and communications technology Institute of Electrical and Electronics Engineers Internet Protocol Millennium Development Goal National Enterprise Architecture non-governmental organization Germanys Standards and Architecture for e-Government Applications Smart Card Operating System for Transport Applications (India) Service-Oriented Architecture United Nations Development Programme Voice over Internet Protocol
viii
Introducing the GIF: Benefits of Interoperability for e-Government
e-Government interoperability is becoming an increasingly crucial issue, especially for developing countries that have committed to the achievement of the Millennium Development Goals (MDGs) by 2015. Enhanced government efficiency and transparency, coupled with the delivery of basic public services to all citizens, are essential components required to achieve such goals. To date, most governments have finalized the design of national e-government strategies and are busy implementing priority programmes. However, these technology investments have not automatically led to more effective public e-services. On the contrary, in many cases, they have ended up reinforcing the old barriers that made access to public services cumbersome not to mention expedient decision-making processes. The e-government promise of more efficient and effective government institutions is not being fulfilled, due to a large extent to the seemingly ad hoc deployment of information and communications technology (ICT) systems. In the short run, these ad hoc deployments address the specific needs of government agencies but they do not pay the required attention to the overall need of interaction among the diverse ICT systems in order to share and exchange data. This collaboration is a key function for e-government institutions such as one-stop shops, which aggregate many public services into one service window. Furthermore, the seamless flow of information across government and between government and citizens increases transparency and accountability. Governments are thus better able to justify their programmes and citizens are better informed all prerequisites for a vibrant democracy.
The promise of e-governance seems more remote because agencies are developing and deploying new ICT systems with specifications and solutions relevant to their particular needs but without adequate attention to the need to connect, exchange, share and re-use data with other ICT systems. Governments should strive for interoperability for a number of reasons. First, e-government interoperability leads to better decision-making. In most countries, policy makers are faced not only with overlapping and uncoordinated data sources but also with the absence of common terms of reference and means of representing these data. This results in the timeconsuming and complex cost of comparing data that is represented differently. Interoperability will allow data compiled by different agencies to be used together to make better decisions. Germanys Federal Foreign Minister, Frank-Walter Steinmeier stated it well: An open, unhindered exchange of information in all areas of life is of fundamental importance for todays knowledge-based society. It is an important foundation for our shared objective: a peaceful, democratic, pluralistic society.1 The second reason is that interoperability allows for better coordination of government agency programmes and services in order to provide enhanced services to citizens and businesses. If information about government is easier to obtain, policy makers can design better projects and can more easily avoid redundant or similar projects. Furthermore, policy- and decision-makers would have more information by which to evaluate the performance of agencies and the public services they deliver.
Message of greeting from Federal Foreign Minister Frank-Walter Steinmeier at the 1st International Open Document Format User Conference at the Federal Foreign Office, Berlin, 29-30 October 2007. http://www.auswaertiges-amt.de/diplo/en/AAmt/071024-IT-ODFWorkshop.html
Introducing the GIF: Benefits of Interoperability for e-Government
The third reason is that interoperability is the foundation of a citizen-centric, one-stop delivery of services through a variety of channels. As noted by the UK e-Government Unit, better public services tailored to the needs of citizen and business require the seamless flow of information across government.2 The fourth reason is that interoperability leads to cost savings and/or cost avoidance. By making systems talk to one another, there may be no need for new systems that were once deemed necessary. Further, demanding interoperability breaks reliance on single vendors and yields choice for governments in their purchases, upgrades and as they scale. Interoperability also promotes international cooperation. Interoperability among governments can help create the infrastructures necessary to solve cross-border problems such as drug trafficking, environmental pollution, money laundering and illegal arms trade.
Interoperability among governments can also mean delivery of e-government services to citizens and businesses across a region (as in the case of the European Union) and facilitate trade between a group of countries and their trading partners (as in the case of the Association of Southeast Asian Nations Single Window initiative). In sum, e-government interoperability contributes to good governance. Interoperability is not only a concern of governments that have already implemented extensive e-government projects or those with extensive legacy systems. In developing countries where e-government is nascent, there is an opportunity to avoid the mistakes of the early adopters. Establishing meta-data (data about data) and other data standards in advance of information digitization and automation will be a means of enabling interoperability in the future.
Box 1: Public security through interoperability in Brazil The public security sector was the first to put in practice the principles and determinations recommended by Brazils GIF (e-PING). The project is called the National System for the Integration of Judicial and Public Security Information (Nosegay) of the Ministry of Justice. Nosegay integrated the public security systems of Brazilian states. This system enables agents of the civil and military police forces and inspectors to have access, in real time, to registers of motor vehicles and persons with outstanding arrest warrants, among other information. By integrating the public security systems of the different states, it is now possible, for example, to identify a criminal on the run from Paran who is being questioned in a police station in Recife regarding a traffic incident. The Nosegay enables the crossing of data of the public security systems with the National Register of Automobiles (Renavam), the National Register of Driving Licenses (Renach), the Arms Registry System (Sinarm) and lists of persons identified as criminals.The National Network of Public Security and Criminal Justice Statistics are also included in the Nosegay. All this integration is accomplished in a speedy and secure manner, in addition to availability with integrity and reliability. XML, web services, Internet protocols and adoption of browsers are the main means to access Nosegay. The cost of Nosegay (i.e. interconnecting existing public security systems of various Brazilian states) is BRL8.5 million. This is less than 1 percent of the estimated cost of the alternative approach building a single unified system for BRL4 billion. Prior to Nosegay, at the end of 2003, only four states were providing partial updates of their information to the Public Security System. Today, Nosegay currently has about 30,000 registered users in more than 200 federal and state entities.
E-Government Unit, Cabinet Office e-Government Interoperability Framework Ver. 6.1, p.5. http://www.govtalk.gov.uk/schemasstandards/egif.asp
2
The GIF: Context
Context can include content under headlines such as: Definitions, aims, objectives, principles, background, audience, benefits and relationship with other initiatives, as in the case of the UKs GIF. Denmark, quite similarly, has these sections: Principles, actors, approach and background.
Approach and scope

A Government Interoperability Framework (GIF) is one way to achieve e-government interoperability. A GIF is a set of standards and guidelines that a government uses to specify the preferred way that its agencies, citizens and partners interact with each other.3 As noted by Luis Guijarro, a GIF includes: ...the basic technical specifications that all agencies relevant to the e-government strategy implementation should adopt4 . A GIF normally includes: Context; Technical content; Process documentation; and Implementation and compliance regimes.5
The approach of this Guide is to elaborate on each of these GIF components and provide some case studies, such as the Brazil example in the introduction. Also note that the introduction above resembles some GIF sections on aims and objectives. Just as GIFs should define their scope, this Guide is focused on interoperability among national government agencies rather than between and among national and local government units. Most of the studied GIFs focused on government-to-government (G2G), government-to-business (G2B) and/or government-to-citizens (G2C), while others had wider scopes including government-to-organizations (G2Org) and government-to-other-governments (G2OG).
Table 1: Scope of various GIFs

G2G Australia Brazil Denmark Germany Malaysia New Zealand UK intermediaries foreign orgs G2C G2B G2Org G2OG Other
European Public Administration Network uses the phrase National Interoperability Architecture where interoperability architecture is seen as a range of complementary technical specifications, systems, standards, guidelines and polices. See European Public Administration Network eGovernment Working Group (EPAN),Key Principles of an Interoperability Architecture. http://www.reach.ie/misc/docs/PrinciplesofInteroperability.pdf Luis Guijarro Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States in Government Information Quarterly, Volume 24, Issue 1, January 2007, p.90. The ideas here are based on a review of the GIFs of Australia, Brazil, Denmark, Germany, Malaysia, New Zealand, the United Kingdom and the EUs European Interoperability Framework (EIF).
The GIF: Context
Open standards
At the heart of a GIF are the standards adopted to ensure interoperability across government. A standard is nothing more than an agreement among independent parties about how to go about doing some task6 Technically, it is a framework of . specifications that has been approved by a recognized organization or is generally accepted and widely used throughout by the industry7 The standards that best . promote interoperability are open standards. According to Eric Sliman: Interoperability results when components are able to work together to complete a process. Open standards, by helping to define component interfaces, increases interoperability. This leads to simpler, repeatable and quicker integration efforts.8 Open standards are usually contrasted with proprietary standards specifications that are owned and controlled by an individual or a corporation. Bruce Perens, who argues for a comprehensive but restrictive view, suggests the following main characteristics of open standards: Availability available for all to read and implement. Maximize end-user choice create a fair, competitive market for implementations of the standard. They do not lock the customer into a particular vendor or group. No royalty free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee. No discrimination do not favour one implementer over another for any reason other than the technical standards compliance of a vendors implementation (applies to the standards and the organization that administers them). Certification organizations must provide a path for low- and zero-cost implementations to be validated, but may also provide enhanced certification services.
Extension or subset implementations may be extended or offered in subset form However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices). Predatory practices may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions and a license for all others to create, distribute and sell software that is compatible with the extensions. An open standard may not otherwise prohibit extensions.9
Not everyone agrees with Perens. Among the most contentious issue in defining open standards is the royalty-free implementation of standards. As noted in Wikipedia, some open standard definitions (like the International Telecommunication Unions) allows reasonable and non-discriminatory licensing.10 For the proponents of the royalty-free implementation, the issue is the added burden that consumers or, in the case of e-government implementation, citizens may have to bear if open standards are not implemented royalty-free. The minimum criteria that have emerged for a standard to be considered open are: Easy accessibility for all to read and use; Developed by a process that is open and relatively easy for anyone to participate in; and No control or tie-in by any specific group or vendor.11
While subtleties in definition vary, the importance of open standards for interoperability is widely accepted. Except for the UK, open standards are directly referred to in all of the GIFs studied. Further, Australia, Germany, Malaysia and New Zealand explicitly state their preference for the use of open standards over proprietary technologies. In the case of the UK, the GIF referred to international standards (some of which are open standards).
6 7
8 9 10 11
Jason Bloomberg and Ronald Schmelzer. Service Orient or Be Doomed. Hoboken, NJ: Wiley & Sons, 2006, p. 35. Nah Soo How. FOSS: Open Standards. Asia-Pacific Development Information Programme e-Primers on Free/Open Source Software, 2006, p. 1. http://www.iosn.net/open-standards/foss-open-standards-primer/foss-openstds-withcover.pdf Eric Sliman.Business Case for Open Standards. http://www.openstandards.net/viewOSnet1C.jsp?showModuleName=businessCaseForOpenStandards Bruce Perens.Open Standards: Principles and Practice. http://www.perens.com/OpenStandards/Definition.html http://en.wikipedia.org/wiki/Open_Standard Nah Soo Hoe.Free/Open Source Software: Open Standards, p. 2.
The Committee for Economic Development reports a key benefit of open standards is that they foster interoperability, allowing disparate devices, applications and networks to communicate12 Rishab Ghosh from . MERIT, University of Maastricht, Netherlands writes: The main advantages of open standards is its capacity to be interoperable with other software systems. This, a software application based on open standards, is fully interoperable with any other application using the same standards, and it is possible for any other application to use the same standard.13 Aside from ensuring interoperability, an e-government programme that is built around open standards will allow public agencies to keep pace with technology innovations and benefit from technology cost reductions. Open standards also avoid vendor lock-in and give governments wider options in terms of technology choices and technology vendors.
Principles
Principles indicate the priorities of government in terms of ICT development. These principles guide the development of the GIF and become the criteria for choosing standards. Many of the GIFs recognized seven similar key principles as described below and highlighted in Table 2. Interoperability guaranteeing a media-consistent flow of information between citizens, business, the federal government and its partners and selecting only those specifications that are relevant to systems interconnectivity, data integration, e-services access and content. Scalability ensuring the usability, adaptability and responsiveness of applications as requirements change and demands fluctuate.
Box 2: SCOSTA open standards and interoperability in India The Smart Card Operating System for Transport Applications (SCOSTA) standard was evolved to address lack of interoperability between smart card technologies for Driving Licenses and Vehicle Registration Certificates being employed by different Indian state governments.The Ministry of Shipping, Road Transport and Highways commissioned the National Informatics Center to make the smart card interoperable with hardware/software being used by different state governments and compliant with the Central Motor Vehicle Rules. In response, the National Informatics Centre developed the SCOSTA open standard. SCOSTA is based on an existing open standard called ISO 7816. ISO 781614 is an international standard related to electronic identification cards, especially smart cards, managed jointly by the International Organization for Standardization and the International Electro-technical Commission.15 The specifications of the new standard are freely available on a public website maintained by the National Informatics Centre. With the adoption of the SCOSTA standard, the number of vendors available to provide cards and card readers increased. Earlier, there were only four or five foreign companies who were marketing smart cards. Now, more than a dozen Indian companies have joined the fray along with their foreign counterparts. This has increased interoperability, reduced prices and increased the bargaining power of the Indian government. By developing an open standard for smart card operating systems, the Government of India was able to reduce intellectual property right rents (related to copyright and patents) for the software. This has resulted in massive savings as the market price of the smart card has dropped from INR300 per card to INR30. Given Indias population and vehicular density, the monetary savings total in the billions. SCOSTAs success in the area of transport applications has resulted in the Ministry of Home accepting the SCOSTA standard for the pilot of a Multi-purpose National Identity Card to be conducted in 10 states and one union territory.16 The Ministry of External Affairs is also considering SCOSTA standards for their ePassport project.
12
13
14 15 16
The Digital Connections Council of the Committee for Economic Development. Open Standards, Open Source and Open Innovation: Harnessing the Benefits of Openness, April 2006, p. 11. http://www.ced.org Rishab A. Ghosh. Open Standards and Interoperability Report: An Economic Basis for Open Standard. Maastricht, 2005. http://flosspols.org/deliverables/D04HTML/FLOSSPOLS-D04-openstandards-v6.html http://www.scosta.gov.in http://en.wikipedia.org/wiki/ISO_7816 http://www.scosta.gov.in/CertificateRelease1.htm
The GIF: Context
Reusability establishing processes and standards for similar procedures when providing services and defining data structures and that consider the solutions of exchange partners that one has to communicate with, leading to bilateral solutions and agreements. Openness focusing on open standards; that is, all standards and guidelines must conform with open standards principles. Wherever possible, open standards will be adopted while establishing technical specifications. Standards that are vendor- and product-neutral should be considered in favour of their proprietary alternatives. Market support drawing on established standards, recognizing opportunities provided by ICT industry trends, and broadening the choice among suppliers. Security ensuring reliable exchange of information that can take place in conformity with an established security policy. Privacy guaranteeing the privacy of information in regard to citizens, business and government organizations, and to respect and enforce the legally defined restrictions on access to and dissemination of information, and ensuring that services need to endure uniform levels of personal data protection.
Multilingualism means that at the presentation level, language is a major factor in the effective delivery of European e-government services. At the back-office level, architecture should be linguistically neutral (in cases where it is not possible,provisions should be made for translation). Transparency is having the e-PING documentation available to society and Internet, and mechanisms for dissemination and the caption and evaluation of suggestions.
Alignment with national strategies

The GIF should be forward-looking and support the wider-encompassing national e-government strategy (or vision of ICT use across government). The wider strategy usually sets out the values and principles for e-government. Tying in the GIF with the more general policy directions of government itself ensures that the GIF is closely aligned with the overall strategy of government. A successful GIF will need to address many challenges, including complex bureaucracies and agencies with entrenched cultures that do not value openness and cooperation with other agencies. These agencies would find it difficult to share data with other agencies. A good example of successful interoperability between multiple agencies aligned with wider national strategies is the one from China described in Box 3. There are also laws and rules that prohibit or limit agencies from exchanging data and information. This includes data protection acts, privacy laws and/or confidentiality of financial records policies. Some national agencies have specific mandates that make it difficult for them to participate in cooperative activities.
Three other unique but noteworthy principles are: Accessibility and Multilingualism in the EUs EIF and Transparency in Brazils e-PING. Accessibility is defined as ensuring that e-government creates equal opportunities for all through open, inclusive e-services that are publicly accessible without discrimination.
Table 2: Principles of various GIFs

Interoperability Scalability Reusability Openness Market support Security Privacy
Australia Brazil Denmark Germany Malaysia UK EU
Box 3: The case of labour insurance in the construction industry in China
The supervision of labour insurance in Chinas construction industry needs the cooperation of the Social Security Department and the Construction Department. The Social Security Department monitors the construction companies to pay the social security, medical insurance, accident insurance and endowment insurance for the workers. Meanwhile, the Construction Department is in charge of examining, approving and supervising construction projects, including how companies hire and manage their employees. Previously, when data-sharing across these two departments had not yet been realized, the Social Security Department was unable to access the employment and labour insurance data for each construction project in an accurate and timely manner. Likewise, the Construction Department was unable to access accurate information regarding whether construction companies had paid insurance for their workers, and therefore could not conduct a thorough evaluation of projects. This lack of efficient data-sharing led to serious flaws in government supervision and provision of services. Now, interoperability has been achieved across the application systems of these two government departments. The Construction Department keeps a record of each construction project, including location, construction schedule and number of workers. These records are then sent to the Social Security Department to monitor whether companies are providing insurance for their workers. The Social Security department is then able to examine the labour insurance payment of each construction company periodically and to inform the Construction Department accordingly. The Construction Department takes these factors into consideration while examining and approving the projects. Through this data-sharing and cooperation across departments, each department is granted access to more information and are therefore better able to supervise and provide services. Ultimately, this means that the rights of construction workers are better protected.17
The most familiar are agencies dealing with national security and public safety agencies. Furthermore, recent public management reforms initiatives18 have not only made the government system more complex, but have also given more autonomy to organizational units in it. It has been the experience of countries implementing GIFs that securing buy-in from government officials in the formulation phase helps create a predisposition for cooperation during the GIF implementation phase,
mitigating some of the problems above. Also, aligning GIFs with the larger development agenda and national strategies will reinforce the benefits and values of these efforts. Beyond this, the following are also important conditions to secure cooperation in GIF implementation: Strong support from the political leadership; Sufficient incentives to stay on the course; and A relatively small number of players.19
17
18
19
Adapted from Li Jinjin. The key needs of the Interoperability (case study). Beijing Zhonghaijiyuan Digital Technology Co., Ltd, China. Shared at the GIF study group meeting and workshop in Beijing, 18-20 April 2007. Such as the New Public Management reform, which endorses disaggregation splitting large bureaucracies into smaller, fragmented ones, competition between different public agencies, and between public agencies and private firms. Hans J. (Jochen) Scholl. Interoperability in e-Government: More than Just Smart Middleware. http://csdl2.computer.org/comp/proceedings/hicss/2005/2268/05/22680123.pdf
The GIF: Context
3
GIF:Technical Content
Technical Content can include: Key technical policy statements, standards, standard categories, standard selection criteria and standard status.
Standard categories
In general, standards that are adopted in existing GIFs fall under the three dimensions of interoperability: Business process or organizational interoperability; Information or semantic interoperability; and Technical interoperability.
Information or semantic interoperability is concerned with ensuring that the precise meaning of exchanged information is understandable by any person or application receiving the data23 Information . interoperability enables systems to combine received information with other information resources and to process it in a meaningful manner24 It also provides a . common methodology, definition, and structure of information, along with shared services for retrieval25 . Technical interoperability is concerned with the technicalities of connecting computer systems for the purpose of exchanging information or using functionality26 It refers to standards and specifications . that would enable coherent exchange of information among computer systems and involves setting principles, standards and guidelines for a common transfer mechanism, developing standardized meta-data and using a common language 27 .
Organizational interoperability is concerned with the coordination and alignment of business processes and information architectures that span both intra and inter-organizational boundaries20 It aims to bring about . the collaboration of administrations that wish to exchange information and may have different internal structures and processes21 Specifically, business process . or organizational interoperability deals with common methods, processes and shared services for collaboration, including work flow, decision making and business transactions22 .
Table 3: Interoperability domain/s of various GIFs

Organizational Australia Brazil Denmark Germany Malaysia New Zealand UK EU
20 21 22 23 24 25 26 27
Information
Technical Yes Yes
Planned Yes
Planned Yes
Yes Yes Yes Yes Yes
Yes
Yes
Yes
European Public Administration Network, Key Principles of an Interoperability Architecture, p. 5. EIF, v1. http://europa.eu.int/idabc/en/document/3761 Australian Government Technical Interoperability Framework (AGTIF) v2. http://www.agimo.gov.au/publications/2005/04/agtifv2 European Public Administration Network (EPAN), Key Principles of an Interoperability Architecture, p.11. EIF, v1, p16. Australian Government Technical Interoperability Framework v2, p 1a. EIF, v1, p. 16. Ibid.
Not all existing GIFs cover all three aspects of interoperability. A survey of eight GIFs reveals that most of them focus on technical rather than organization or information/semantic interoperability (see Table 3). The typical route taken by several countries is to address the technical dimensions of interoperability first. This could be because addressing technical interoperability is the easiest to do. It is also the case that a number of countries reviewed the plan to tackle other dimensions of their interoperability in their respective National Enterprise Architecture (NEA). The EU and German frameworks grouped standards according to services (i.e. job search, income tax declaration, enrolment in university, etc.) and used these to address the three dimensions of interoperability. Australia, Brazil, Denmark, Malaysia, New Zealand and the UK approached interoperability by addressing the technical aspect, such as: Interconnection standards related to networks and system development, which layer enables communications between systems. Data integration standards for the description of data that enables exchange between disparate systems. Content management and metadata standards for retrieving and managing government information. Information access and presentation presentation of data to the user in the various means of access to e-government services. Business services standards to support data exchange in particular business areas such as e-learning, e-health, etc. Web-based services standards to connect and integrate web-based applications over the Internet.
Security standards that ensure safe access and exchange of information in public services. In most instances, the security cuts across all technical interoperability layers. Sometimes, however, the security layer is a stand-alone layer.
Another layer that can be included is a best-practice layer. And in Germanys GIF (SAGA), an applications layer has been included.
Standards selection
While most of the studied GIFs favoured open standards, in some cases, proprietary standards are recognized when no open standard exists. For this reason, the GIF principles are important to consider in standard selection as the setting of values for e-government and the GIF. It is also critical that the philosophy that animates the selection of the standards be clearly articulated in the GIF, such as a Principles section found earlier in this Guide. Having clear and well-known principles and criteria will help prevent an uncritical adoption of the standards, particularly when new standards emerge and previous ones have not been retired. For instance, the rigid insistence of using any particular standard may constrain a government from using old standards that respond to all previous needs as well as to new ones. Mandating a particular technology will not only prevent government from using the latest and the best but also consign it to using older and perhaps outmoded standards. The philosophy behind choosing standards in the GIF must be well-defined and understood by all relevant parties to preclude an uncritical use of standards in government. One way of achieving this is to publish the standard selection criteria so that all stakeholders have knowledge of it and can take it into account when developing new standards or specifications.
Table 4: GIF layers

Data integration Content management and metadata Information access and presentation Business services Web-based services
Interconnection
Security
Australia Brazil Denmark Malaysia New Zealand UK
10
Selection criteria could mirror the overall principles of the GIF as discussed earlier and/or specific standards criteria could be developed. A good starting point would be to look at the recommendations made for standards-setting for the Internet. These principles include: Allowing for Diversity and Democratic Participation in order to ensure that interests other than those of direct stakeholders have a chance to be represented and for legitimate consensus to be possible. Exhibiting Informational Openness and Transparency so that, at a minimum, multiple stakeholders can access standards specifications, and so that institutional affiliations and policy deliberations become transparently accessible to the public. Defining Intellectual Property Rights Constraints to prevent manipulation of standards for rent-seeking and market dominance. Subscribing to principles of Universal Access and Security to support a global competitive market and the compatibility of new technologies within growing interdependent systems. 28
recognized the life-cycle of standards as they identify three basic categories, which most (excluding Australia) further subdivide: Emerging under development (or future consideration) and under review (observation or evaluation); these either have yet to be appraised, are being evaluated by committees or via pilot projects, and/or have potential in line with intended development trends but are not yet categorized. Current recommended/approved and adopted/ mandatory (interestingly, some countries such as Denmark and New Zealand use recommended as the higher status, while Brazil and the UK use recommended as the status below adopted); these are formally reviewed and accredited, tried and tested, have ongoing support, and are considered mature and/or crucial for interoperability. Fading de-facto/sustained and transitioning/ migrating from/depreciated or not to be used as in the black list German classification; these standards do not comply with one or more of the technical requirements as set up in the general policies of the architecture; they are standards and technologies that, while still used, are receiving less support, and/or have been abandoned for a better solution.
Clearly articulating the philosophy behind the standards chosen also builds flexibility in the GIF. Flexibility is important partly because standards follow a life-cycle of emergence to obsolescence. As it is inevitable that standards will change, it is important to address how the framework can be designed to anticipate and accommodate change. A worthwhile idea to consider is to insert a sunset clause on some of the standards selected. Most of the studied GIFs
Lastly, a good GIF must respond to realities that specific governments face. For instance, the use of mandatory, recommended standards in the GIF depends on the particular level of maturity of the countries implementing the GIF.
Table 5: Standards maturity and obsolescence

Emerging
Under development Under review
Current
Recommend Mandatory Sustained
Fading
Depreciated
Australia Brazil Denmark Germany New Zealand UK
28
Eddan Katz and Laura DeNardis.Best Practices for Internet Standards Governance. http://www.intgovforum.org/Substantive_1st_IGF/BestPracticesforInternetStandardsGovernance.pdf
11
4
GIF Development Process
Development process can include: Development and revision process, actors and responsibilities, and mechanisms for consultation, as in New Zealands GIF.
GIF development actors

Assigning responsibility to a GIF Lead Agency or Project Office, in the case of South Africa and Malaysia, ensures that the GIF development process has an institutional base to support its activities. Creating a lead body means providing personnel, budget and other logistical needs. Aside from organizational support, the lead agency could have the final recommendatory power in approving the GIF. It also acts as the rallying centre for all efforts at implementing the GIF. A GIF Secretariat serves as the organizational base of GIF development. The Lead Agency can create a unit and assign within their agency the personnel to act as the GIF secretariat or build a Secretariat from across agencies. In short, the GIF Secretariat oversees the operations of the GIF document from development to approval to revision, etc. The GIF Secretariat can be responsible for translating the lead bodys GIF vision into a plan of action. The format of the GIF, division of tasks and timetables are normally the responsibility of the Secretariat. However, actual work on the technical policies can be assigned to the GIF Working Group(s). The Secretariat is also responsible for the logistical preparations for activities on GIF development such as workshops or conferences. Aside from operational work, the Secretariat also coordinates with the different stakeholders involved in the GIF development process. This involves selecting members of the Working Groups who are from other government agencies. If there are other supporting players, such as industry representatives or nongovernmental organizations (NGOs) who will be involved in the process, the Secretariat has to ensure their participation. When the draft GIF is to be presented for public consultation, this process will be managed by the Secretariat.
Lastly, the Secretariat performs documentation functions. It collects recommendations submitted by the working groups. The Secretariat can sometimes comprise GIF joint authors along with the working groups. The Secretariat prepares the GIF version for release to the public. The GIF Working Group, comprised of experts from various government agencies, is the technical body that works on standards selection. In the case of the UK GIF development, the Working Group shared many of the functions of the GIF Secretariat. It was the Working Group, not the Secretariat, that decided on the format and content of the GIF. In such an instance, the GIF Secretariat becomes a coordinating body and the Working Group assumes the direction-setting role. In another scenario, the functions of the GIF Secretariat and the GlF Working Group are lodged in one body. In the case of Denmark, the IT Architecture Committee is both GIF Secretariat and Working Group. The same is true for Malaysias ICT Policy and Planning Division. The Lead Agency, the Secretariat and the Working Group(s) are the main actors in GIF development. Other agencies and organizations play a supporting role for two reasons to ensure support for the document (buy-in) and for quality control. If it is true that a successful standard is one that is widely used, it is prudent to involve all government agencies in GIF development. Representatives of public sector agencies can participate in the development process through various mechanisms. Malaysia conducted consultations with government agencies regarding the GIF. For Australia and Denmark, the lead authorities are representatives from different government agencies. For New Zealand and the UK, government agencies act as individual contributors by filing their comments or complaints regarding the specifications contained in the GIF.
13
Some countries have used the services of Independent Expert Groups in the development of their GIF. Australia, Germany and the UK have expert groups outside of the working groups.These expert groups can be comprised of senior IT personnel, as in the case of the UK, or be a private consultancy group, as in the case of Australia. These expert groups function as an advisory group or as an independent review committee to the GIF document. Wider stakeholder participation, involving industry, NGOs and citizens, is also important to GIF development. The ICT industry has an important role to play in GIF development and implementation. Industry input to the GIF is important since industry is usually at the cutting edge of technological development. In the UK, industry representatives are included in the Working Groups. And, as previously mentioned, a private corporation
acted as external consultants to review the contents of the Australian GIF. Lastly, consultation mechanisms such as websites, emails and discussion forums can be used to elicit industry contributions to GIF development. The participation of NGOs should also be welcomed. NGOs usually articulate the views of the users and consumers of online government services. Taking their views into account could help formulate a better GIF. Citizens can participate in the GIF development through public consultation mechanisms that could be put in place by the GIF Secretariat. Citizen perspective is important to evaluate the impact and the usability of the specifications in the GIF to the end user. The mechanisms for eliciting public participation are: Websites including wikis and emails; Public hearings; and Requests for comments and requests for proposals.
Figure 1: From GIF Version 0 to Version 1

Tasks
Establishment of a GIF Secretariat
Responsibility
Lead Authority
Creation of action plan, time tables, Working Groups
GIF Secretariat
Review other GIFs, internal needs and national ICT strategies
GIF Secretariat
Draft initial GIF outline
GIF Secretariat
Draft principles, definitions, goals and selection criteria
Working Groups
Release v0 for consultation or informal review
GIF Secretariat
Solicit input and contributions from experts, other government agencies, industry, the public
GIF Secretariat and Working Groups
Re-draft v0 to incorporate contributions and develop technical content more fully
Solicit input from experts, etc.
GIF Secretariat
Re-draft v0.5 to incorporate contributions, refine principles, technical content and add governance structures
Release v0.9 for approval Re-draft v0.5 to incorporate contributions, refine principles, technical content and add governance structures Approval of document
GIF Secretariat
Minister, Cabinet (as appropriate)
Release v1 for policy use
Lead Authority
14
Creating the GIF

There is not a one-size-fits-all approach to creating the GIF, as many governments have already independently taken their own important steps towards achieving interoperability. GIFs can grow from existing projects, be part of broader ICT policies, or be a stand-alone document. This Guide focuses on the latter and suggests one approach. Regardless of how a government begins, having a pragmatic approach meaning matching the realities within government and the marketplace is most important. One method is to identify the Lead Agency, Secretariat and Workings Group(s) that have been established and that consultations with citizens, NGOs, etc., as described above, are taking place. Early actions might also include: drafting the action plan with timetables, reviewing
GIFs in other countries and resources available, and assigning tasks for the whole process, including details for specific deliverables from Working Group(s). The Working Group activities would consist of: Conducting further research on existing e-government technologies and needs, suggesting principles and standard-selection criteria, and placing specific standards and specifications in the appropriate life-cycle categories. The first draft of the GIF is submitted for consultation either to the public or to an independent expert group. The Working Group incorporates any changes and comments to the GIF. The reworked version of the draft is forwarded by the secretariat for formal review to the lead authority or policy maker. The lead authority either provides corrections to the draft or approves it for use.
Figure 2: From GIF Version 1 to Version 2

Tasks
Continuous inputs via consultation mechanisms
Responsibility
GIF Secretariat
Monitoring and compilation of contributions
GIF Secretariat
Review other GIFs, internal e-government developments, etc.
GIF Secretariat
Create working groups and provide list of topics for review
GIF Secretariat
Review existing technical policy and specifications
Working Groups
Draft v1.1- v1.3
Release v1.3 for consultation and informal review
GIF Secretariat
Solicit input and contributions from all stakeholders
Re-draft v1.3 to incorporate contributions
GIF Secretariat
Release v1.5 for formal review
GIF Secretariat
Re-draft v1.5 to incorporate contributions
Release v1.9 for approval
GIF Secretariat
Approval of document
Minister, Cabinet (as appropriate)
Release v2 for policy use
Lead Authority
15
Revising the GIF

While it is important to get the GIF right, it is also true that governments will have to revise their GIFs. Achieving interoperability is an iterative process, where drafting, piloting and implementing all inform and enable improvements when studied. In fact, most existing GIFs stipulate an annual GIF revision and updating process. This updating process is established to ensure that the standards included in the GIFs remain relevant to the technological environment. Figure 2 shows a stylized procedure for revising the GIF.
No government will ever achieve interoperability in one single step. Achieving interoperability is a process of many incremental steps coming together over time. Among others, technologies will change, processes will change, standards will become obsolete, and new standards will emerge. As the case of the UK eGIF clearly shows, the GIF is a document that will continue to evolve to adapt to changing circumstances.
Box 4: The evolution of UK eGIF The main thrust of the UK eGIF Version 1 (Oct 2000) is to adopt the Internet and World Wide Web standards for all government systems. It is a strategic decision to adopt XML and XSL as the core standards for data integration and presentation. This includes the definition and central provision of XML schemes for use throughout the public sector. The eGIF also adopts standards that are well supported in the marketplace. It is a pragmatic strategy that aims to reduce cost and risk for government systems whilst aligning them to the global Internet revolution. The main sections of the e-GIF are Overview, Policies and Technical Standards, Implementation Support, and Management Processes. Policies and Technical Standards are categorized into Interconnection policies and specifications, Data Integration policies and specifications, and Information Access policies and specifications. Six months after the above was formulated, eGIF Version 2 (April 2001) was released. Version 2 has new sections on content delivery and WAP access standards and specifications. Some sections remain the same. Other changes include: 1) The standards to be used for service delivery by mobile phones; 2) Guidance on content delivery and the potential uses of trans-coders, i.e. technologies that enable web content to be delivered to a variety of destination environments; 3) Guidance on linking the eGIF to the work of public sector communities; 4) Support for low functionality browsers and viewers; 5) Provision of the ability to support the citizen in their own time and at their own pace, i.e. asynchronously; and 6) Separation of interoperability issues from presentation and user interface ones. eGIF Version 3 (released in Autumn 2001) included a new section on complying with the GIF. Specifications on Mobile Access were also improved. Other changes include: 1) Alignment with European Commission procurement rules; 2) Advice on the protection of sensitive information; 3) Guidance on the move from Internet Protocol (IP) v4 to v6; 4) Guidance on emerging specifications; 5) Support for access by ethnic minorities and the disabled; 6) Revisions to basic and additional browser specifications; 7) Changes to the management groups; 8) Further details of the compliance processes; and 9) New appendix of abbreviations and acronyms. The main change in the UK eGIF Version 4 is the separation of the Technical Policies and Specifications from the Framework. Part 1 maintained the same sections Policy and Scope, Implementation Support, Management Processes, and Complying with the GIF. Part 2 contained the Technical Policies and Specifications categorized according to Interconnection, Data Integration, Content Management Metadata, Information Access, and Specifications for Business Areas.
16
The eGIF Version 5 is still divided into two parts. The main change for Part 1 (Framework) is the section on Change Management which used to be a topic included in Management Processes. For Part 2, a major change is in the classification of standards in to A-Adopted, R-Recommended, U-Under Consideration and F-Future Consideration. Another change is the addition of Specifications for access smart cards in the Access category. The UK eGIF Version 6 saw changes in Parts 1 and 2. The main changes for Part 1 are: 1) The expansion of Management Processes to include delineation of tasks among GIF players (e-Government Unit,Working Groups, citizens, public sector; 2) Updates on the Change Management processes to include more specific consultation procedures; and 3) Inclusion of Technical Policies as one of the sections. Part 2 of the eGIF Version 6 is renamed the Technical Standards Catalog. The Interconnection category now has a separate topic on Web Services Specifications. The Information Access category has been renamed e-Services Access. e-Services Access has expanded its specifications to cover Voice over Internet Protocol (VoIP) systems and more detailed aspects of smart cards. Specifications for business areas are also expanded to cover the following areas - e-Learning, e-Health and Social Care, Finance, Commerce, Purchasing and Logistics, and Work Flow and Web Service. A lot of the specifications for smart cards, VoIP and business areas are still under consideration.
17
5
GIF Implementation and Governance
The Implementation and Compliance section can include: Implementation support tools such as those in the Denmark and UK GIFs, interoperability indicators, responsibility for compliance, stakeholders, guide tools and non-compliance such as in the UK GIF.
Agency responsibilities
Interoperability governance, following the European Public Administration Network (EPAN): is concerned with the ownership, definition, development, maintenance, monitoring and promotion of standards, protocols, policies and technologies 29 . EPAN recommends that a single agency should be responsible for technical and semantic interoperability aspects of the GIF. This GIF governing agency should have the following characteristics and should be: Separate from all sectoral domains to ensure independence; Seen as expert in the field of interoperability to engender trust; Capable of working as a collaborative partner with fulfilment agencies and sectors; Proactive in the promotion and promulgation of standards and their use; Responsible for monitoring usage of and policing adherence to standards, guidelines, policies and protocols; Singularly focused on standardizing and providing interoperability on a pan-public service basis; and An advisory body to fulfilment agencies in developing strategies, implementing solutions, coordinating cross-agency aggregated services and to communities of practice in setting and publishing standards.30
EPAN also believes that, depending on national circumstances, a separate agency could be in charge of Organizational Interoperability Standards and Approaches.31
Compliance
While it is easy to mandate that all government agencies comply with the GIF, there is no guarantee that agencies would follow said mandate. The scope of the GIF and how it was developed will effect its compliance. Having initial buy-in will help drive wider compliance. Also, scoping appropriately can help for example, having the GIF apply to new procurements first and then move to incorporate older systems. It would also be prudent for governments to adopt an incentives-based approach to GIF compliance. The most common version of this approach is linking the GIF with the budget: only GIF compliant e-government projects will receive new funding. This is particularly effective if all ICT projects are funded centrally and the GIF lead agency has effective control over the use and disbursement of this fund. In this scenario, noncompliant projects will not be funded by government. A variation of this scenario is a central fund for e-government that supplements or augments agency funds for ICT projects. While this still allows non-GIF compliant projects to be funded,it can be seen by agencies as a less high-handed approach to GIF compliance.
29 30 31
EPAN Key Principles, p. 11. Ibid, p. 31. Ibid, p. 32.
19
Attention must also be paid to procurement policies, criteria and evaluations to ensure compliance. In purchasing new software, governments may consider the advice of Rishab Ghosh: A recommendation for public policy for effective support for interoperability, therefore, must start with a mandatory requirement not to include compatibility with previously purchased software as a selection criterion for new software. Rather, interoperability with software from multiple vendors must be the sole compatibility criterion for new software.32 It is also important for governments to create incentives to foster a culture of re-use in the system. The business motivators for re-use are readily available today; cost reduction and flexibility and responsiveness in IT architectures and underlying systems. In line with this, funds could be reduced and not allocated to projects that duplicate existing initiatives. Recognition to agencies that re-use applications or services can also be given. This can take the form of an annual recognition event or ceremony. Another way to promote compliance is to build a community that will support the standards endorsed by the GIF. This community, acting as a support group, would be composed of both users and suppliers of GIF compliant technologies and/or services. The existence of such a community will also be helpful to those implementing projects that use the GIF standards for the first time. This method is similar to how international standards organizations ensure standards compliance. The emergence of user communities dedicated to using and promoting standards is also how market-based standards emerge.
empower an agency to secure compliance but should not be overly specific or too detailed on what standards are mandated. The specific standards should be defined in regulation, since it is easier to update. Another possible enforcement mechanism is the establishment of an Interoperability Certification. The Certification represents an agencys interoperability level. It is presumed that this is another way to encourage agencies to adopt the GIF specifications. Lastly, publishing reference manuals on how to build systems that are compliant to the GIF positively re-enforces GIF standards. Building actual prototypes and distributing its source codes, documentation, and design to other agencies would be helpful to other agencies that are just starting to develop their own systems.
Capacity development
It is critical to undertake efforts to disseminate information as well as to educate and train government personnel on the GIF and the standards that it prescribes.This is to ensure that interoperability takes its due place at both strategic and practical levels. Investments in capability development in management, and in system and service procurement, as well as the IT skills required for effective implementation of standards-based e-government services can only be avoided at the risk of GIF failure.
Metrics
Defining metrics or measures of success is also very important in GIF governance. However, defining metrics of interoperability is not easy as interoperability is not an absolute. It is not an all-or-nothing state and, as many researchers have found out, interoperability is difficult to measure: ... true interoperability is much more than just connectivity. It is also a function of operational concepts and scenarios, policies, processes, and procedures. For this reason, developing and applying precise measurements in an area as multidimensional and complex as interoperability is difficult.33
Enforcement
One enforcement strategy is to adopt a gating process to approve projects. Projects should be regularly reviewed as they are being implemented and include the possibility of stopping the project that has not followed the original specifications. Random inspection of major ICT projects is also a way of enforcing GIF standards. In instances when legislation is necessary for GIF enforcement, the new law should be broad enough to
32
33
Rishab A. Ghosh. Open Standards and Interoperability Report: An Economic Basis for Open Standard. Maastricht, 2005. http://flosspols.org/deliverables/D04HTML/FLOSSPOLS-D04-openstandards-v6.html John Hamilton, Jerome Rosen, Pauk Summers.Developing Interoperability Matrix. http://www.eng.auburn.edu/users/hamilton/security/spawar/6_Developing_Interoperability_Metrics.pdf
20
While difficult, many have taken on the challenge. Among them is Dr. Lee Whitt, who proposes an interoperability test for the system view composed of ten external interfaces tests and ten internal context tests.34 Mark Kasunic and William Anderson offer four sets of measures to address interoperability: technical compliance; systems interoperability; operational interoperability; and organizational and cultural interoperability.35
A useful basic test has been offered by John Hamilton, Jerome Rosen and Paul Summers in their Developing Interoperability Matrix. They propose that for interoperability to happen, a system should meet at least one of the following requirements: Generate data that is used by another system; Process or consume data that is generated by another system; Rely on another system for the delivery of data; or Be software that operates on the same platform as another system.36
While governments might not need very precise metrics, some basic measurements can help to determine the success of the GIF.
34
35
36
Dr. Lee Whitt.The Good, The Bad, and The Ugly of Interoperability Metrics. February 2004. http://www.opengroup.org/public/member/proceedings/q104/ges-whit.pdf Mark Kasunic and William Anderson.Measuring Systems Interoperability: Challenges and Opportunities. April 2004. http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn003.pdf Hamilton, Rosen and Summers.Developing Interoperability Matrix.
21
Architectural Approaches to Interoperability
In addition to achieving interoperability through GIFs and their standards, Architectures have an important role in ensuring e-government interoperability successes. The relevance and relationship of Architectures to interoperability is highlighted in this sections definitions, objectives, principles, technical content, development and governances of Architectures, both Enterprise-Wide and Service-Oriented.
Defining Enterprise Architecture and Service-Oriented Architecture

Architecture, according to the Institute of Electrical and Electronics Engineers (IEEE), is: the fundamental organization of a system embodied by its components and their relationships to each other and to the environment and the principles guiding its design and activity37 For our purpose, the relevant architecture to . discuss is Enterprise Architecture (EA), specifically National Enterprise Architecture (NEA). An Enterprise Architecture is a strategic planning framework that relates and aligns ICT with the business functions that it supports. The Danish government describes its EA as a: common framework that ensures general coherence between public sector IT systems, at the same time as the systems are optimized in terms of local needs. It is a common framework with a view to quality improvement, resource optimization and cost reduction.38 Marijn Janssen and Kristian Hjort-Madsen, who use the phrase National Enterprise Architecture, define it as a framework or umbrella for explaining the relationships among the governments ICT projects and managing change. For them architecting public administration involves designing public administrations to reflect the
political and public managers decisions at a strategic level in operational activities and decisions.39 Thus, the NEA fills the gap between policy and implementation. Recently, it has been suggested that a Service-Oriented Architecture (SOA) is the best underlying paradigm with which to begin to roll out e-government services that can be used in cross-agency and cross-border situations.40 SOA is an enterprise-wide IT architecture that promotes loose coupling, re-use, and interoperability between systems41 Its proponents argue that SOA offers a better . way of designing integrable, re-usable application assets, orchestrated from existing services rather than rebuilt from scratch42 Furthermore, it closes the . business/IT alignment gap created by the traditional development approach. What distinguishes SOA is its implementation of a service platform consisting of many services that signify elements of business processes that can be combined and recombined into different solutions and scenarios, as determined by the business needs43 This . capability to integrate and recombine services is what gives a service-oriented enterprise the agility needed to respond quickly and effectively to new situations and requirements.
37 38 39
40
41 42 43
Cited in Bloomberg and Schmelzer. Service Orient or Be Doomed, p. 118. (Denmark) Ministry of Science, Technology and Innovation.White Paper on Enterprise Architecture, p.16. http://www.oio.dk/files/whitepaper.pdf Marijn Janssen and Kristian Hjort-Madsen.Analyzing Enterprise Architecture in National Governments: The cases of Denmark and the Netherlands. Proceedings of the 40th Hawaii International Conference on System Sciences, 2007. http://csdl2.computer.org/comp/proceedings/hicss/2006/2507/04/250740071c.pdf Peters Pensieve OASIS Symposium Service-Oriented Architecture and e-Government Panel. http://www.xmlbystealth.net/blog/2007/04/oasis-symposium-soa-and-egovernment.html Biebertein. et al. Service Oriented Architecture Compass, p. 4. Bringing SOA Value Patterns to Life: An Oracle White Paper, p 5. http://www.oracle.com/technologies/soa/soa-value-patterns.pdf Norbert Biebertein, Sanjay Bose, Marc Fiammente, Keith Jones and Rawn Shah. Service Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap. Upper Saddle, NJ: IBM Press, 2006, p. 3.
23
Objectives
The Danish government believes that its NEA can help meet the following objectives: Ensure better public service through higher quality IT support; Support the development of innovative crossfunctional administrative processes through greater coherence in information; Achieve more efficient administration through more efficient use of IT; Provide the capability for fast support of new or modified administrative processes or organizational changes through access to tried-and-tested infrastructure solutions; Provide easier access to public information through open interfaces between citizens, companies and authorities; Provide adequate protection of public information through secure solutions for handling and exchanging data; Create more successful IT solutions through greater predictability of the results of IT investments; and Provide a solid platform for public administration through stable IT systems with sufficient capacity (underscoring in the original).44 While NEAs can be implemented to secure interoperability, as in the case of Denmark, other countries such as the Netherlands and the US use NEA to reduce red tape in order to reap positive long-term effects on economic growth, employment and income. The US government started its work on its Federal Enterprise Architecture (FEA) in February 2002, with the purpose of identifying opportunities to simplify processes and unify work across the Federal government, with an ultimate goal to transform the Federal government to one that is citizen-centered, results-oriented, and market-based . To achieve this, the FEA has its objectives to: Identify opportunities to leverage technology and alleviate redundancy, or highlight where agency IT overlap reduces the value of investments; Facilitate horizontal (cross-federal) and vertical (federal, state and local) integration of IT resources; Apply architecture practices to help drive business management improvements across the federal government; and
44 45 46
Support a citizen-centred, results-focused government that maximizes IT to better achieve mission outcomes and fulfil legislative mandates.45 The government of Canada has adopted an SOA to cut through the current information silos, promote interoperability and enable services to be delivered more effectively and uniformly46 SOA is seen as a useful approach to the governments programme design, strategic business planning, as well as systems design. It is also seen as a means of achieving the Canadian governments goals for service modernization, horizontal service delivery and greater interoperability. In the government of Canadas SOA,Service Orientation in a business context is defined as: the planning and delivery of all services by formally componentizing each of the services and their subordinate services such that the overall collection of services work as a whole and supports a high level master-plan (or strategic design)47 . Service-orientation depicts the delivery of any valued output via a service from one party to another. By using SOA in government, the Canadian government believes it can achieve the following: Facilitate the manageable growth of large-scale enterprise systems; Provide a simple scalable paradigm for organizing large networks of systems that require interoperability; Minimize trust assumptions among providers and consumers to further promote greater business agility and autonomy; and Integrate functionality across ownership boundaries.48 As a service orientation defines the needs and outcomes of e-government in terms of services, independent from the technology (the hardware platform, operating system and programming language) that implements them, its benefits for governments are: adaptability, predictability and accountability.49 China is choosing a technical plan based on SOA or loose-coupling, according to Liu Jinjun, President, BZDT Co, Ltd. He adds, since the government departments have built up their operations application systems independently, we shall consider making the most use of all existent systems and infrastructures while making effort to achieve interoperability. The wasting of previous investment shall be minimized.50
47
48 49 50
Ibid., p. 19. http://www.whitehouse.gov/omb/egov/documents/FEA_Overview.pdf Government of Canada. Service Oriented Architecture Strategy Statement of Direction, p 6. http://www.tbs-sct.gc.ca/cio-dpi/webapps/architecture/sd-eo/sd-eo00_e.asp Government of Canada. Service Oriented Architecture Strategy Statement of Direction, p 3. http://www.tbs-sct.gc.ca/cio-dpi/webapps/ architecture/sd-eo/sd-eo00_e.asp Ibid., pp. 6-7. Peters Pensieve. http://www.xmlbystealth.net/blog/2007/04/3-main-benefits-of-soa-for-egovernment.html Li Jinjin, President of Beijing Zhonghaijiyuan Digital Technology Co., Ltd, China. The key needs of the Interoperability, shared at the GIF study group meeting and workshop in Beijing, 18-20 April 2007.
24
Architectural principles
Any government considering interoperability through architecture should adopt architectural design principles that would realize its goals, which are similar to GIF design principles or guidelines, and are textual statements that describe the constraints imposed upon the organization, and/or the decisions taken in support of realizing the business strategies and can be used to guide future projects51 . In 2003, Denmark published a White Paper on Enterprise Architecture which outlines five principles for public sector EA: Interoperability, Security, Openness, Flexibility and Scalability, which nearly mirror the principles shared earlier in this Guide. Marijn Janssen and George Kuk, who endorse the idea of adopting complex adaptive system theory in the design of an NEA, believe that the design of enterprise architecture has to balance between excessive and no controls, and allow flexibility and adaptability such that systems are not frozen because they are tightly constrained or disintegrate due to little order52 They . suggest that governments should consider the following guiding principles for architectural design: Stimulate/breed diversity encourage variety within the system, as diversity allows for the creation of new possibilities to co-evolve with their environment. From an ICT perspective, an ICT monoculture is generally fragile and cannot effectively respond to the changing needs of an organization. However, stimulating/breeding variety should be done with care. Conditions such as reusability and cost justification should be defined without disputing the autonomy of the initiatives. Set targets as well as constraints setting targets without constraints results in a variety of heterogeneous systems and accompanying interoperability problems. Stimulate growth of successful projects the basic idea behind this principle is to breed initiatives that might become successful and result in best practices. Develop standard infrastructure components the reuse of available and proven infrastructure components can help to develop new systems more quickly and bring costs down.
Develop modular architectures instead of being involved in the design of complex systems architectures, focus should be on defining the basic component functionality and interfaces. This should constrain the variety of systems and ensure that the systems can interoperate with each other. Stimulate sharing sharing of ICT-departments, functionalities and services helps to reduce costs and also increases available budgets, providing access to expertise and systems formerly out of reach. Develop competencies mechanisms should be in place to develop knowledge and capabilities that are necessary to use and integrate the infrastructure components and other results of the programme. Stimulate the formation of coalitions agencies tend to do things on their own and resist government-wide initiatives. Coalitions with participants from various agencies also create the opportunity to breed new ideas.53
Technical content
Like in interoperability, open standards are the backbone of a service-based approach. They ensure flexibility so that criteria and decisions are serviceoriented and technology-neutral. They enable managers to combine, mix and match, and replace components without the expense and expertise of custom coding connections between service components. As in GIF, EAs can be divided into technical components or layers. The US FEA consists of five inter-related reference models that are designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. The reference models are: Performance a framework for performance measurement providing common output measurements throughout the federal government. Business a framework facilitating a functional (rather than organizational) view of the federal governments lines of business, including its internal operations and its services for citizens, independent of the agencies, bureaus and offices performing them.
51
52
53
Marijn Janssen and George Kuk A Complex Adaptive System Perspective of Enterprise Architecture in Electronic Government. Proceedings of the 39th Hawaii International Conference on System Sciences, 2006, p.3. http://csdl2.computer.org/comp/proceedings/hicss/2006/2507/04/250740071b.pdf Marijn Janssen and George Kuk.A Complex Adaptive System Perspective of Enterprise Architecture in Electronic Government Proceedings of the 39th Hawaii International Conference on System Sciences, 2006, p.3. http://csdl2.computer.org/comp/proceedings/hicss/2006/2507/04/250740071b.pdf Ibid, pp. 6-8.
25
Service Component a business-driven, functional framework classifying Service Components according to how they support business and performance objectives. Technical a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. Data a flexible and standards-based framework to enable information-sharing and re-use across the federal government via the standard description and discovery of common data and the promotion of uniform data management practices.
Building an NEA or SOA is a huge and complex undertaking requiring both skills and significant amount of resources. The challenges faced by governments building an NEA/SOA are the same as those countries implementing a GIF bureaucratic obstacles, governance issues, inadequate information dissemination and human capital requirements. The Danish White Paper on Enterprise Architecture shared the following recommendations on development and design: The public sector...should take more active responsibility for its own EA. A common EA framework should be established for planning public sector IT systems, with special regard for ensuring interoperability. There should be a concerted effort to spread knowledge of and develop competencies in EA, especially in relation to joint public sector initiatives.55
Development and design

There are a number of public-service specific issues that governments should consider when developing their EA or SOA. First, in architecting public service, it is imperative to design what is needed for and by the public citizens, employees, NGO and businesses and not design based on technology that is available. A technology-led approach to NEA will not achieve its goals of greater interoperability and more effective and efficient public services. Second, getting the architecture right will accelerate the delivery of services to citizens and lead to cost savings. In its 2007 FEA Assessment, the US Office of Management and Budget noted that the majority (19 out of 24) agencies studied were realizing IT cost savings, cost avoidance, and/or satisfactory programme performance54 The Office of Management and Budget . also believes that further cost savings/avoidance can still be realized if agencies give more focus to this objective. In the case of an SOA, cost savings/cost avoidance is due to reusable services. Third, architecture should support the overall vision of flexible public service. Advances in open standards and software-development tools have made both responsive EA and SOA possible. It would be tragic if despite this development, governments adopt an architecture that limits its ability to respond quickly despite changing conditions.
Implementation and governance

As has been pointed out in the section on GIF Governance, interoperability is as much a political as it is a technical issue. For ICT-enabled systems to talk to each other through architecture there needs to be a desire and a will. Furthermore, the elements of success include: Cooperation of various government agencies; Appropriate incentive structure; and Strong and demonstrated support from political leaders. The Open Group which promotes The Open Group Architecture Framework considers architecture governance a key to successful Enterprise Agency implementation.56 It has also been argued that Service-Oriented Governance isnt optional its imperative. Without it, return on investment will be low and every SOA project out of the pilot phase will be at risk57 The four critical areas that SOA governance . should address are: Establishing decision rights; Defining high-value business (government) services; Managing the life-cycle of assets; and Measuring effectiveness.58
54 55 56 57 58
http://www.whitehouse.gov/omb/egov/documents/2007_EA_Assessment_Results_Summary.pdf Ministry of Science, Technology and Innovation White Paper on Enterprise Architecture p. 5. http://www.oio.dk/files/whitepaper.pdf TOFAF. http://www.opengroup.org/architecture/togaf8-doc/arch/ Paolo Malinverno, cited in Sandy Carter, The New Language of Business: SOA & Web 2.0. Upper Saddle NJ: IBM Press, 2007, p 105. Ibid., p. 116.
26
There is also a need to extensively communicate the architecture to increase awareness, understanding and use, particularly among the ICT community. Aside from writing and promoting the architecture, the Canadian province of Ontario conducts an annual Enterprise Architecture Open House to discuss the latest progress in EA as well as the ways in which businesses and IT have worked together successfully through EA. In terms of skills, NEA/SOA formulation and implementation requires individuals with both business and technical know-how. As an example of the skills that an Enterprise Architect should possess, a Terms of Reference could include the following requirements: Systems thinking the ability to see how parts interact with the whole (big picture thinking); Knowledge of the business for which the EA is being developed;
Interpersonal and leadership skills collaboration, facilitation and negotiation skills; Emotional Intelligence self awareness, confidence, ability to manage conflict, empathy; Communication skills - both written and spoken; Ability to explain complex technical issues in a way that non-technical people may understand; Knowledge of IT governance and operations; Comprehensive knowledge of hardware, software, application and systems engineering; Project and programme management planning and organization skills; Knowledge of financial modelling as it pertains to IT investment; Customer service orientation; and Time management and prioritization. 59 Aside from having people with the right skills, there is also the need to have the right number of people.
59
http://en.wikipedia.org/wiki/Enterprise_architect
27
Conclusion: Policy, Not Technology, Matters
The GIF and the NEA are two related approaches to interoperability. One way of looking at the two is to see the GIF as a building code and the NEA as a town plan. Like a building code, a GIF is a set of rules that specify what standards are to be used. In the same manner, the NEA can be seen as a town plan, where common resources are provided for and rules for their use are defined. The third approach to interoperability is where architecture and standards are included in one document. This approached is exemplified by Germanys Standards and Architecture for e-Government Applications (SAGA). However one approaches interoperability be it through a GIF, NEA or hybrid such as SAGA there is no avoiding the need to produce a technically sound document. Also, GIFs, EAs and SOAs are developed and measured based on critical common principles: Scalability; Reusability; Flexibility; Openness; and Security. But the success of the GIF or the NEA is not only based on how strong it is as a technical document, but also how well it supports the overall goals of a flexible public service and good governance.
It is important to remember that the issue of interoperability emerged as a result of a wealth of independent e-government projects, which often have limited coherence and remain largely uncoordinated. A GIF/NEA/SOA must demand and create interoperability focused on obtaining more efficient, effective and transparent ICT-enabled governance. To enable interoperability across government, one does not start with technology. One starts with the governments strategic framework and the vision and goals of its leaders. This is even more the case in developing countries with governments that have already committed to key development goals and are striving to reduce poverty and enhance good governance in the short and medium term.
Conclusion: Policy, Not Technology, Matters
29
Bibliography
Books, monographs
Allen, P., with S. Higgins, P. McRae and H. Schlamann (2006). Service-Orientation: Winning Strategies and Best Practices. Cambridge: Cambridge University Press. Biebertein, N., S. Bose, M. Fiammente, K. Jones and R. Shah (2006). Service Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap. Upper Saddle, NJ: IBM Press. Bloomberg, J. and R. Schmelzer (2006). Service Orient or Be Doomed. Hoboken, NJ: Wiley & Sons. Carter, S. (2007). The New Language of Business: SOA & Web 2.0. Upper Saddle, NJ: IBM Press. http://www.iosn.net/open-standards/foss-open-standards-primer/foss-openstds-withcover.pdf Nah, S. H. (2006). Free/Open Source Software: Open Standards. Asia-Pacific Development Information Programme e-Primers on Free/Open Source Software. http://www.iosn.net/open-standards/foss-open-standards-primer/foss-openstds-withcover.pdf
Journal articles, proceedings

Guijarro, L. (2007).Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States, in Government Information Quarterly, volume 24, issue 1, January 2007. Hamilton, J., J. Rosen and P. Summers.Developing Interoperability Matrix. http://www.eng.auburn.edu/users/hamilton/security/spawar/6_Developing_Interoperability_Metrics.pdf Hjort-Madsen, K (2006).Enterprise Architecture Implementation and Management: A Case Study on Interoperability. Proceedings of the 39th Hawaii International Conference on System Sciences, 2006. http://csdl2.computer.org/comp/proceedings/hicss/2006/2507/04/250740071c.pdf Janssen, M. and K. Hjort-Madsen (2007).Analyzing Enterprise Architecture in National Governments: The cases of Denmark and the Netherlands. Proceedings of the 40th Hawaii International Conference on System Sciences, 2007. http://csdl2.computer.org/comp/proceedings/hicss/2007/2755/00/27550218a.pdf Janssen, M. and G. Kuk (2006).A Complex Adaptive System Perspective of Enterprise Architecture in Electronic Government. Proceedings of the 39th Hawaii International Conference on System Sciences, 2006. http://csdl2.computer.org/comp/proceedings/hicss/2006/2507/04/250740071b.pdf Kasunic, M. and W. Anderson (2004).Measuring Systems Interoperability: Challenges and Opportunities. April 2004. http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn003.pdf Scholl, H.J. (2005).Interoperability in e-Government: More than Just Smart Middleware. Proceedings of the 38th Hawaii International Conference on System Sciences, 2005. http://csdl2.computer.org/comp/proceedings/hicss/2005/2268/05/22680123.pdf Whitt, L. (2004).The Good, The Bad, and The Ugly of Interoperability Metrics. February 2004. http://www.opengroup.org/public/member/proceedings/q104/ges-whit.pdf
Bibliography
31
White papers, web pages, blogs

European Public Administration Network eGovernment Working Group (2004). Key Principles of an Interoperability Architecture. http://www.reach.ie/misc/docs/PrinciplesofInteroperability.pdf Ghosh, R.A. (2005). Open Standards and Interoperability Report: An Economic Basis for Open Standard. Maastricht, 2005. http://flosspols.org/deliverables/D04HTML/FLOSSPOLS-D04-openstandards-v6.html Katz, E. and L. DeNardis (2006). Best Practices for Internet Standards Governance. http://www.intgovforum.org/Substantive_1st_IGF/BestPracticesforInternetStandardsGovernance.pdf Perens, B. (2007). Open Standards: Principles and Practice. http://www.perens.com/OpenStandards/Definition.html Peter's Pensieve OASIS Symposium (2007). SOA and eGovernment Panel. http://www.xmlbystealth.net/blog/2007/04/oasis-symposium-soa-and-egovernment.html The Open Group (2007). The Open Group Architecture Framework 8. http://www.opengroup.org/architecture/togaf8-doc/arch/ Oracle (2006). Bringing SOA Value Patterns to Life: An Oracle White Paper. http://www.oracle.com/technologies/soa/soa-value-patterns.pdf Sutor, B. (2007). Interoperability More or Less, in Bob Sutors Open Blogs. http://www.sutor.com/newsite/blog-open/?p=1372 Wikipedia (2007).Enterprise Architect http://en.wikipedia.org/wiki/Enterprise_architect , Wikipedia (2007).Open Standard http://en.wikipedia.org/wiki/Open_standard ,
Official documents
Australia Chief Information Officer Committee. Australian Government Technical Interoperability Framework, version 2. Brazil e-Government Executive Committee. Standards of Interoperability for Electronic Government (e-PING), version 2.01, published December 20. Canada Treasury Board Secretariat. Government of Canada Service Oriented Architecture Strategy Statement of Direction . Treasury Board Secretariat. Government of Canada Service Oriented Architecture Series: Primer. Denmark Ministry of Science, Technology and Innovation (2005). Danish e-Government Interoperability Framework (DIF), version 1.2.14, published June 2005. Ministry of Science, Technology and Innovation (2005). White Paper on Enterprise Architecture. European Union European Commission IDABC. European Interoperability Framework, version 1. Germany Federal Ministry of the Interior (2006). Standards and Architecture for e-Government Applications (SAGA), version 3.0, published October 2006.
32
Malaysia Malaysian Administrative Modernisation and Management Planning Unit (2006). The Malaysian Government Interoperability Framework for Open Source Software (MyGIFOSS), published 2006. Malaysian Administrative Modernisation and Management Planning Unit (2003). Standards, Policies and Guidelines Malaysian Interoperability Framework (MyGIF), version 1.0, published August 2003. New Zealand State Services Commission (2006). New Zealand e-Government Interoperability Framework (NZ e-GIF) , version 3.0, published March 2006. United Kingdom eGovernment Unit, Cabinet Office. e-Government Interoperability Framework (e-GIF), version 6.1. United States CIO Council (2001). A Practical Guide to Federal Enterprise Architecture, version 1, February 2001. Office of Management and Budget (2007). Federal Enterprise Architecture Assessment. Office of Management and Budget (2005). Enabling Citizen-Centered Electronic Government, 20052006, FEA PMO Action Plan.
Bibliography
33
Acknowledgements
The UNDP Regional Centre in Bangkok, publisher of the GIF series, would like to express its gratitude to Dr. Emmanuel C. Lallana for his dedication and efforts in steering the drafting process and seeking input from its members by moderating all the discussions at the GIF Study Group Meeting in Beijing. Dr. Lallana has created the substance of the reports and consistently consulted with study group members during the development of the GIF series.Thanks to Kathryn V. Pauso for assisting Dr. Lallana in the process. UNDP also wishes to express its gratitude to the study group members for being in Beijing to share their experiences, and for providing input and case studies in the drafting process. UNDP expresses its gratitude to IBM and Oracle for not only sponsoring the project but also for contributing substantively with valuable inputs in the interactive discussions in Beijing, and for providing ideas and inputs throughout the process. Particularly, we wish to thank Roslyn Docktor and Peter Lord for taking the time to participate in numerous teleconferences and helping us to achieve the desired outputs. Moreover, we would like to extend our thanks to industry partners who provided their perspective on the subject at the GIF Study Group Dialogue with Industry and Other Stakeholders in Beijing on 20 April 2007. Shahid Akhtar, former Programme Coordinator of APDIP, initiated the project and without his dedication and network of contacts in the region, the project would not have been possible. Thanks also to Lars Bestle, who managed the project, and Christine Apikul, who coordinated the development of the GIF series. Finally, we would like to thank the following individuals for providing and sharing ideas, knowledge, insight and observations throughout the preparation process: Chanuka Wattegama, Sunil Abraham, Joan McCalla, Raul Zambrano, Norman Sanders, James George Chacko, Leandro Corte and Jantima Sirisaengtaksin.
Acknowledgements
35
This series on e-Government Interoperability comprises three publications An Overview, A Guide and A Review of Government Interoperability Frameworks in Selected Countries. e-Government interoperability leads to better decision-making, better coordination of government agency programmes and services, cost savings and/or cost avoidance, and is the foundation of a citizen-centred, one-stop delivery of services. The series aims to assist countries who are striving to set up or improve interoperable ICT frameworks for better e-government delivery. The Overview provides a quick introduction on the what, who, why and how of e-government interoperability and is aimed at policy makers. The Guide is a practical tool for technical officials and policy makers who plan to draft or revise a Government Interoperability Framework (GIF). The Review provides a comparative analysis of eight existing GIFs and serves as a useful resource for those involved in the development or revision of a GIF.
Overview The Overview introduces and guides policy makers to the what, who, why and how of e-government interoperability. Through a question-and-answer format, the publication walks its readers through the vision, rationale and value of GIF and a National Enterprise Architecture (NEA). It answers some fundamental questions such as what are the resources required, who should be involved and what are the key factors for its successful development and operationalization. It also looks at open standards and what they have to do with GIF. This Overview is particularly useful for senior officials in governments who are starting to implement their e-government strategies and for those who are planningto develop a GIF or NEA.
Guide The Guide is a practical tool for technical officials and policy makers in governments who plan to draft or revise a GIF to ensure e-government interoperability among national government agencies. It is a comprehensive guide giving details on the approaches and principles of a GIF, and the standards categories and selection processes. It provides a step-by-step guide to developing and revising a GIF, illustrated with relevant case studies. This Guide also provides guidance on operationalizing the GIF, examining key issues related to implementation, compliance, enforcement and capacity development.
Review The Review provides a comparative analysis of eight existing GIFs of Australia, Brazil, Denmark, the European Union, Germany, Malaysia, New Zealand and the United Kingdom. It serves as a useful resource for government officials, the corporate sector and civil society involved in the development or revision of a GIF. This Review focuses on how GIFs in different countries were developed, the principles that animate them, the technical standards they mandated and/or recommend, the way these GIFs are managed, and the implementation and compliance mechanisms they established.
United Nations Development Programme Regional Centre in Bangkok 3rd Floor, UN Service Building Rajdamnern Nok Avenue Bangkok 10200, Thailand Tel: +66 2 288 2129 Fax: +66 2 288 3032 Email: [email protected] Website: http://regionalcentrebangkok.undp.or.th

Egov Report UN

Uploaded by

Copyright:

Available Formats

Egov Report UN

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Egov Report UN

Uploaded by

Copyright:

Available Formats

e-Government Interoperability: Guide

e-Government Interoperability: Guide

United Nations Development Programme with the support of IBM Oracle

Copyright 2007 UNDP

Design and layout: Keen Media (Thailand) Co., Ltd.

Elizabeth Fong Regional Manager UNDP Regional Centre in Bangkok

e-Government Interoperability: Guide

UNDP GIF Study Group Members

UNDP GIF Study Group Members

e-Government Interoperability: Guide

Introducing the GIF: Benefits of Interoperability for e-Government

Introducing the GIF: Benefits of Interoperability for e-Government

e-Government Interoperability: Guide

Approach and scope

Table 1: Scope of various GIFs

The GIF: Context

e-Government Interoperability: Guide

The GIF: Context

Alignment with national strategies

Table 2: Principles of various GIFs

Australia Brazil Denmark Germany Malaysia UK EU

e-Government Interoperability: Guide

Box 3: The case of labour insurance in the construction industry in China

The GIF: Context

Table 3: Interoperability domain/s of various GIFs

Technical Yes Yes

Yes Yes Yes Yes Yes

Table 4: GIF layers

Australia Brazil Denmark Malaysia New Zealand UK

e-Government Interoperability: Guide

Table 5: Standards maturity and obsolescence

Australia Brazil Denmark Germany New Zealand UK

GIF development actors

GIF Development Process

Figure 1: From GIF Version 0 to Version 1

Creation of action plan, time tables, Working Groups

Review other GIFs, internal needs and national ICT strategies

Draft initial GIF outline

Draft principles, definitions, goals and selection criteria

Release v0 for consultation or informal review

GIF Secretariat and Working Groups

Re-draft v0 to incorporate contributions and develop technical content more fully

GIF Secretariat and Working Groups

Solicit input from experts, etc.

GIF Secretariat and Working Groups

GIF Secretariat and Working Groups

Minister, Cabinet (as appropriate)

Release v1 for policy use

e-Government Interoperability: Guide

Creating the GIF

Figure 2: From GIF Version 1 to Version 2

Monitoring and compilation of contributions

Review other GIFs, internal e-government developments, etc.

Create working groups and provide list of topics for review

Review existing technical policy and specifications

Draft v1.1- v1.3

GIF Secretariat and Working Groups

Release v1.3 for consultation and informal review

Solicit input and contributions from all stakeholders

GIF Secretariat and Working Groups