project number: ala/2002/47-446/1087 project...

Deliverable Number: D.2.1

Subproject contributing to Deliverable: SP2

Contractual Date of Delivery: 15.03.2004

Actual Date of Delivery: 15.03.2004

History: Version 1.0

Editor(s): P. Hoepner and M. Mendes

Reviewer(s): eGOIA partners

Keyword List: eGOIA, e-government, Latin America, requirements, constraints, public service access, general principles, standards, service selection

Project Number: ALA/2002/47-446/1087

Project Acronym: eGOIA

Project Title: Electronic GOvernment Innovation and Access

Title of Deliverable: eGOIA Diagnosis

eGOIA - Electronic GOvernment Innovation and Access Deliverable D.2.1: eGOIA Diagnosis

Version V1.0 15.03.2004 - /93 -

(This page is intentionally left blank)


Version V1.0 15.03.2004 - /93 -

Executive Summary

The main goal of EU @LIS project “Electronic GOvernment Innovation and Access (eGOIA)” being an @LIS demonstration project is the provisioning of demonstrators that show future-oriented public administration services to a broad public in Latin America. The vision of the eGOIA project is the provision of a single virtual space supporting the interaction of citizens (independent of social status, gender, race, abilities and age) and the public administration in a simple, future-oriented and cost-effective way. eGOIA aims to demonstrate an e-Government system based on an open services infrastructure in order to allow the access of citizens through the Internet to integrated public services at several levels: local (municipalities), regional (state governments) and federal (federal governments).

One main objective of eGOIA Subproject 2 is to create the common project vision for eGOIA, which is presented within this document.

In summary this deliverable D.2.1. encompasses the background information and initial requirements and principles for the demonstrator. Background information covers the current e-Government situation in Latin America, applications and services such as Poupatempo, best practice examples from Europe and Latin America, relevant standards, initiatives, existing technology and infrastructures. Also functional and non-functional requirements (e.g. social, organizational, technical, political, financial, economical, security requirements etc.) from different points of view of the stakeholders are gathered. The boundary conditions, i.e. the constraints for the demonstrations within the eGOIA project are inspected such as laws and regulations, financial constraints, standards to be applied, available infrastructure, employee persuasion and education. The general principles of the demonstrator are established that comprise a highly complex distributed environment and are based on the viewpoint-oriented system modeling as specified in the international standard of the Reference Model for Open Distributed Processing (RM-ODP). Finally the eGOIA demonstrator will show future-oriented public administration services to a broad public. Emphasis is put on the main demonstrator in São Paulo (Brazil). The achieved results will be transferred to other Brazilian states, to Peru and back to Europe, i.e. to Portugal. To gather the preconditions for the eGOIA demonstrator the current situation of existent e-Government programs in Brazil, Peru and Portugal were analyzed and combined with the rich experience in public administration services of the eGOIA partners.

Brazil initiated the creation of Citizen’s Services Centers (such as Poupatempo in São Paulo State) in almost all the Brazilian states, which gather several agencies carrying out services from any area of the government in a unique space. However, the facility introduced by these Centers contributed to the performance of hundreds of services in a single physical space but does not resolve all the problems of the citizens. The great challenge presented in Brazil, and in particular in São Paulo, is the possibility of the construction of virtual citizen’s services centers, where the access to public services and information without the obligatory repeated certifications is possible. This will establish a new form of relationship between State and citizen. An Electronic Government (e-GOV) Program was launched in Brazil, under the leadership of the Presidency of the Republic. This program has several similarities with the objectives stated in eGOIA.

Peruvian e-Government is just barely in its infancy. Growth is predicted for the next several years, as in all of Latin America, but Peru still has major steps to take. Several good practices examples in e-government can be recognized: The Registry Information System (SIR), the System of Automatic Acquisitions and Contracts for the Peruvian Government (SEACE) and an Automated Voting System.

Portugal approved a new Portuguese Information Society strategy in November 2002, which closely follows the guidelines of the eEurope 2005 Action Plan. Portugal has a solid base of services developed for citizens, especially in the regulation sector. Examples are the registry agency Direcção Geral dos Registos e do Notariado and Portugal’s public services online portal (INFOCID - Portal da Administração Pública Portuguesa).

By its partners eGOIA transfers technological experiences in the conceptual definition, architectural construction and deployment of public services from Berlin, Germany. Several projects in the Berlin


Version V1.0 15.03.2004 - /93 -

City Administration, like VeZuDa, BLIS and a life-situation based information system – Start-Infosystem – will strongly influence the architecture of the eGOIA Demonstrator.

Various initiatives and organizations are currently operating to define, standardize and enforce e-Government services such as the eEurope 2005 Action Plan, IDA (Interchange of Data between Administrations), an European Commission driven strategic initiative, BundOnline2005, the e-Government program of the German government with the German “Standards and Architectures for e-Government Applications (SAGA)”, the UK GovTalk consultation processes and the e-Government Interoperability Framework (e-GIF) in UK and the USA OMB’s Federal Enterprise Architecture Program Management Office (FEAPMO) defining the Federal Enterprise Architecture (FEA).

The eGOIA demonstrator requirements are based on the different needs, constraints and organizational information of the target environment with respect to social, organizational, technical, political, legal, financial, economical, security and other aspects. The interests and needs of the eGOIA user groups such as citizens, employees of the public administration, administrators, etc. are of major importance in establishing a distinguished set of requirements by applying a requirement engineering process. The evaluation of requirements will be supported by developing a hierarchical, multidimensional and weighted list of requirements, which can be applied to the dependency of benefit, requirements and assessment.

The selection of e-Government services is a major task in the eGOIA project. It is essential for the outcome of the project and provides valuable experiences for the ongoing development of the e-Poupatempo system. Service selection for the eGOIA demonstrator will be based on a combination of pragmatic and ideal criteria. Since it will be hardly possible to assess in depth every service, the eGOIA project applies a combination of criteria that ensures as much as possible the highest pay-off with the minimal risk, while taking into account the characteristics of the technology available to the project. The basic targets and principles of the service selection strategy are described. The final selection of the services to be demonstrated is not handled in this document but is part of the strategy planning as well as a major working area of the technical subprojects of eGOIA.

The eGOIA Demonstrator will be an e-Government demonstration system that will support the interaction of citizens with different types of e-Government services through the Internet and Citizen Points of Access (CPAs). For such it will comprise the integration of:

• Back-office procedures: integration of services and access of existing distributed databases for the benefit of the citizen,

• Front-office procedures: supporting appropriated access channels and the functionalities of the services.

These integration tasks are not at all simple techniques. Therefore technological tendencies in the IT area are analyzed and an architecture concept is introduced. This concept views and divides the e-Government system and services into different aspects (viewpoints) and so the complexity of the overall architecture is reduced. The advanced technology thereby becomes more understandable and thus more controllable. To increase reusability of software and to enforce future-proof solutions the development of software models independently of the infrastructure is emerging, as provided by MDA (Model Driven Architecture). MDA supports a late and dynamic generation of run-time systems, also considering the details of operational systems, communication and middleware used.

The principles of the demonstrator and the approach taken by eGOIA can be summarized as follows: The conception of the eGOIA demonstrator has to take into account that it has to be possible to use applications in an open and distributed environment (Internet), and to be configured in flexible way taking into account the evolution of the involved government departments. The design and implementation will be carried out in several stages. The eGOIA architecture will be a multi-tier architecture. Following the architectural object-oriented principles, the applications will be independent of the existing infrastructure. The initial point of the development of the eGOIA Demonstrator will be the analysis of selected services and its use (use cases). In that analysis, also the real databases involved in these services will be identified as well as the government's departments that manage them. Simultaneously, we will capture the specific requirements and develop an operational scenario to be put in place in form of the eGOIA demonstrator.


Version V1.0 15.03.2004 - /93 -

LIST OF CONTRIBUTORS

Name Company E-mail

Adriana Figueiredo CenPRA [email protected]

Agnaldo Lopes SGGE [email protected]

Alfonso Molina Helios [email protected]

Alvaro Gregorio SGGE [email protected]

Aqueo Kamada CenPRA [email protected]

Cristina Sá Meticube [email protected]

Elke Jäger INI-GraphicsNet [email protected]

Jarbas Lopes Cardoso Júnior CenPRA [email protected]

Joachim Rix INI-GraphicsNet [email protected]

João Noveletto CenPRA [email protected]

José Gonzaga CenPRA [email protected]

Jürgen Bund Meticube [email protected]

Linda Strick FOKUS [email protected]

Luciano Damasceno CenPRA [email protected]

Manuel Mendes CenPRA [email protected]

Marcos Rodrigues CenPRA [email protected]

Maurício de Moraes SGGE [email protected]

Petra Hoepner FOKUS [email protected]

Georg Rainer Hofmann INI-GraphicsNet [email protected]

Renato Borelli CenPRA [email protected]

Sergio Bollinger SGGE [email protected]

Romildo Monte CenPRA [email protected]

Tomasz Kusber FOKUS [email protected]

Uwe Holzmann-Kaiser FOKUS [email protected]

Vera Lucia Tokairim SGGE [email protected]


Version V1.0 15.03.2004 - /93 -

TABLE OF CONTENTS

Executive Summary 3

List of Contributors 5

Table of Contents 6

List of Figures 9

List of Tables 10

Acronyms 11

1 Introduction 12 1.1 Scope and Objectives of Subproject 2 12 1.2 Document outline 13

2 Terminology 15

PART I: EXISTING KNOWLEDGE 17

3 The Situation of Public Service Access 18 3.1 Brazil 18

3.1.1 Federal Situation 18 3.1.2 Regional Situation 19

3.2 Peru 19 3.3 Portugal 20

4 e-Government Services and Good Practice Examples 23 4.1 Brazil 24

4.1.1 Federal Good Practices 24 4.1.2 São Paulo State Good Practices 25

4.2 Peru 26 4.3 Germany - Berlin 27 4.4 Portugal 28

5 Frameworks, Architectures, Standards and Initiatives 29 5.1 Brazil 29

5.1.1 Public Key Infrastructure 29 5.1.2 Brazilian Payment System 29

5.2 European Union 30 5.2.1 eEurope 2005 Action Plan 30 5.2.2 IDA Initiative 30

5.3 Germany – BundOnline2005 Program 31 5.3.1 Standards and Architectures for e-Government Applications (SAGA) 31 5.3.2 Dedicated Standard for Secure e-Government Transactions - OSCI 33 5.3.3 e-Government Manual 34

5.4 United Kingdom – e-GIF 35


Version V1.0 15.03.2004 - /93 -

5.5 USA - FEA 35

PART II: GENERAL REQUIREMENTS AND CONSTRAINTS 36

6 Generic eGOIA Demonstrator Requirements and Constraints 37 6.1 Requirements Engineering Process 37 6.2 Stakeholder Requirements 37

6.2.1 Citizen Needs 37 6.2.2 Civil Servant Needs 39

6.3 Organizational and Domain Requirements 39 6.3.1 Organizational Requirements 39 6.3.2 Financial Constraints 40 6.3.3 Ownership and Intellectual Property Rights 40 6.3.4 Legacy Systems and Legacy Databases 40 6.3.5 Physical Infrastructure 41 6.3.6 Observation of Current Developments 41 6.3.7 Dissemination Constraints 41

6.4 Regulations and Legal Requirements 41 6.5 Functional and Non-functional Requirements 42

6.5.1 Functional Requirements 42 6.5.2 Non-Functional Requirements 43

6.6 Hierarchical, multidimensional Set of weighted Criteria for Requirements Engineering 44 6.7 Security in e-Government 45

6.7.1 Protection Aims 45 6.7.2 Protection Requirements 46 6.7.3 Authentication 46

7 Service Selection Principles 49 7.1 Stages of Online Availability 49 7.2 Types of Online Services 50 7.3 Important Public Services 50 7.4 Criteria for eGOIA Service Selection 51

PART III: GENERAL PRINCIPLES OF THE EGOIA DEMONSTRATOR 53

8 General Principles of the eGOIA Demonstrator 54 8.1 Technical Aspects 54

8.1.1 New Technologies 54 8.1.2 RM-ODP Viewpoints 55 8.1.3 Modeling 56

8.2 Concepts of the eGOIA Demonstrator Architecture 58 8.2.1 Enterprise Viewpoint 58 8.2.2 Information Viewpoint 60


Version V1.0 15.03.2004 - /93 -

8.2.3 Computational Viewpoint 60 8.2.4 Engineering viewpoint 61 8.2.5 Technology viewpoint 62

PART IV: CONCLUSIONS AND RECOMMENDATIONS 64

9 Conclusions, Recommendations and Future Work 65 9.1 Conclusions 65

9.1.1 Existing Knowledge 65 9.1.2 Good Practices of eGOIA Partners 65 9.1.3 Technical Frameworks and Standards 66 9.1.4 General Demonstrator Requirements and Constraints 67 9.1.5 Selection Principles of eServices 68

9.2 General Principles of the eGOIA Demonstrator: Recommendations 69 9.3 Outlook to the Work of the other eGOIA Subprojects 70

9.3.1 Outlook to D.2.2 70 9.3.2 Outlook to SP3 71 9.3.3 Outlook to SP4 71 9.3.4 Outlook to SP5 72

10 References 73

ANNEXES 75

Annex A Detailed Description of Relevant Projects 76 A.1 Project VeZuDa 76 A.2 VeZuDa Application - BLIS 79 A.3 Discourse Support System - ZENO 81 A.4 ZENO Application - DEMOS 82

Annex B Detailed Description of Relevant Supporting Information 83 B.1 Germany – e-Government Manual 83 B.2 USA: e-Gov Enterprise Architecture Guidance 84

Annex C Detailed Description of Relevant Technology 87 C.1 Service Integration Platform - EnagoOSP 87 C.2 Tools for Service Creation 91


Version V1.0 15.03.2004 - /93 -

LIST OF FIGURES

Figure 1: Definition of the eGOIA Demonstrator ................................................................................... 13

Figure 2: Best practice factors for e-Government projects.................................................................... 24

Figure 3: Overview of the Basic Components for e-Government in German SAGA............................. 32

Figure 4: Requirements engineering process ....................................................................................... 37

Figure 5: Requirements Strategy .......................................................................................................... 45

Figure 6: EDOC Mapping of Languages for ODP Viewpoints............................................................... 58

Figure 7: Overview of Domains in the eGOIA Demonstrator Community............................................. 60

Figure 8: Multi-tier structure of eGOIA Demonstrator ........................................................................... 62

Figure 9: Development Process ............................................................................................................ 76

Figure 10: VeZuDa Business Model...................................................................................................... 77

Figure 11: VeZuDa Environment........................................................................................................... 78

Figure 12: BLIS Access......................................................................................................................... 80

Figure 13: BLIS Architecture ................................................................................................................. 80

Figure 14: Phase model of DEMOS system.......................................................................................... 82

Figure 15: FEA Reference Model.......................................................................................................... 85

Figure 16: EnagoOSP architecture ....................................................................................................... 87

Figure 17: e-Government Business Model............................................................................................ 88

Figure 18: Service Development Support through Development Frameworks..................................... 91

Figure 19: Tool-supported Development Process................................................................................. 92

Figure 20: Modeling Infrastructure ........................................................................................................ 93


Version V1.0 15.03.2004 - /93 -

LIST OF TABLES

Table 1: Authentication.......................................................................................................................... 48

Table 2: ODP Viewpoints ...................................................................................................................... 55

Table 3: Concerns Addressed by the ODP Viewpoints......................................................................... 57

Table 4: Correlation of ODP Viewpoint Models with OMG Models....................................................... 57


Version V1.0 15.03.2004 - /93 -

ACRONYMS

CIM Computation-Independent Model (MDA)

CORBA Common Object Request Broker Architecture

CPA Citizen Points of Access

CRM Customer Relationship Management

EDOC Enterprise Distributed Object Computing

e-GIF e-Government Interoperability Framework (UK)

eGOIA Electronic Government Innovation and Access

e-GOV Electronic Government. The same as e-Government

EIF European Interoperability Framework

FAQ Frequently Asked Questions

FEA Federal Enterprise Architecture (USA)

FEAPMO Federal Enterprise Architecture Program Management Office (USA)

G2C Government to Citizen

G2E Government to Employee

G2G Government to Government

G2B Government to Business

ICT Information and Communication Technology

IDA Interchange of Data between Administrations (EU Initiative)

IS Information Society

J2EE Java 2 Enterprise Edition

LA Latin America

MDA Model Driven Architecture

ODP Open Distributed Processing

OMG Object Management Group

OSCI Online Service Computer Interface (e-Government standard in Germany)

PDA Personal Digital Assistant

PIAP Public Internet Access Points

PIM Platform-Independent Model (MDA)

PKI Public Key Infrastructure

PSM Platform-Specific Model (MDA)

R&D Research and Development

RM-ODP Open Distributed Processing Reference Model

SAGA Standards and Architectures for e-Government Applications (Germany)

SP Subproject

UML Unified Modeling Language™

XML Extensible Markup Language


Version V1.0 15.03.2004 - /93 -

1 INTRODUCTION

“e-Government is the use of Information and Communication Technologies in public administrations combined with organizational change and new skills in order to improve public services and democratic processes and strengthen support to public policies. However, many barriers and obstacles need to be overcome and sizeable investments are needed. Change processes in organization and culture take time: it can take several years before the combined investment in ICT, organization and skills deliver the full benefits.” [1]

1.1 Scope and Objectives of Subproject 2

The main objective of eGOIA Subproject 2 is to create a common project vision for eGOIA, see Figure 1, by executing a set of activities:

• Knowledge: Examination of e-Government current situation in Latin America (LA), applications and services such as Poupatempo, SAC and Vapt-Vupt, good practice examples from Europe and LA, relevant standards and initiatives and existing technology and infrastructures towards their applicability to eGOIA.

• Demands: This activity aims to identify functional and non-functional requirements (e.g. social, organizational, technical, political, financial, economical, security requirements etc.) and from different points of view of the stakeholders. The interests of the eGOIA partners and user groups (stakeholders) have to be analyzed and evaluated. The user groups consist of citizens, employees of the public administration, administrators, etc and must take into account all their social and physical diversity. eGOIA focuses on G2C (government to citizen) demonstrations. G2B and G2G (government-to-business and the government-to-government) scenarios and applications may be of interest in later versions of the demonstrator.

• Constraints: Constraints are requirements that postulate boundaries for the design, implementation and deployment of the eGOIA demonstrator. These constraints can be of different nature, for example legal constraints, financial constraints, technical constraints and organizational constraints such as the available infrastructure, employee persuasion and education, etc. Considering constraints and external conditions for planning, developing, building and running an e-Government system, it should be clear – and carefully distinguished – that there are qualitative as well as quantitative effects. Non-quantitative and non-rational – (nevertheless existing) - reasons to refuse a system or to refuse a proposed application scenario have to be taken into account as well.

These three main activities will be used as a basis to define the general principles of eGOIA demonstrator supporting the transformation of the current state of the government systems to the target state, that is, a real enterprise integration able to offer a set of services to the different user groups.


Version V1.0 15.03.2004 - /93 -

General Principles of the eGOIA

Demonstrator

Knowledge

Demands Constraints

Conclusions Recommendations

Good practice, standards, technologies

What the demonstrator should provide Limitations

Figure 1: Definition of the eGOIA Demonstrator

General Principles of eGOIA demonstrator will be worked out and described, based on the knowledge, demands and constraints with the main focus on demonstration to the user groups and the back-office integration. The demonstrator will be used as an experimental system to be tested and evaluated.

Conclusions and Outlook to other Subprojects will be developed to achieve compliance with the project objectives and to provide guidelines for the adjacent subprojects and future work.

1.2 Document outline

The document is organized in four parts according to Figure 1 above, covering

• Existing knowledge of project partners

• General requirements and constraints (demands and constraints) of the eGOIA demonstrator

• General principles of the eGOIA demonstrator

• Conclusions and recommendations

The annexes contain detailed descriptions of the relevant projects and supporting information.

Chapter 1 introduces the scope and objectives of Subproject 2 of the eGOIA project. The terminology used in eGOIA and in this document is described in Chapter 2.

Part I of this document contains three chapters focusing on existent knowledge of the participating partners. Chapter 3 describes the current situation of public service access in the three target countries for the eGOIA demonstrator. Being a demonstration project eGOIA strongly is based on good practice examples known and/or provided by the participating partners. These good practice examples are described in Chapter 4. To define a future-proof solution, eGOIA takes into account the


Version V1.0 15.03.2004 - /93 -

current developments and standardization activities of e-Government initiatives as described in Chapter 5.

Part II of this document contains two chapters comprising the general requirements of the eGOIA demonstrator. Chapter 6 describes the requirements and constraints identified by the project partners. Chapter 7 focuses on the service selection principles taken into account to choose suitable services for the project demonstrations.

Part III of this document contains one chapter, Chapter 8, concentrating on the general principles and architectural decisions for the eGOIA demonstrator from different viewpoints based on the ODP standard. The technical aspects are outlined.

Part IV of this document contains one chapter, Chapter 9, which describes the conclusions regarding the demonstrator and recommendations for the work of the succeeding Subprojects of the project.


Version V1.0 15.03.2004 - /93 -

2 TERMINOLOGY

Authentication (procedure)

The authentication procedure refers to the verification of a user authentication, i.e. a check to determine whether a communication partner is actually the person he claims to be.

Authenticity

The term authenticity designates the property that guarantees that a communication partner is actually the person he claims to be or that the provided information was actually generated by the specified source.

Availability Guarantee that whenever users need information and services, they can be called and used as required and within the projected time.

Certificate (key certificate)

Electronic certificate used to assign signature verification keys to a person.

Confidentiality Guarantee that data and information are accessible only to authorized parties and in the permitted way.

Content The static or dynamic information that authorities provide to citizens through the portal. The content can be closely related to the service or it can be information of news/instruction type.

Criterion/Criteria See selection criterion. Digital signature Mechanism for ensuring the security of electronic data in which a value

is generated from the information using a private key. This value can then be verified using the associated public key. The digital signature is used to protect the authenticity and integrity of the data.

Integrity Ensuring that information and data is not corrupted. In electronic communications, this means that the data has not been modified during transfer.

IT security Synonym for security in information technology. It refers to the observance of certain security standards relating to the availability, integrity and confidentiality of information by means of security mechanisms 1. in information technology systems or components or 2. in the use of information technology systems or components

IT security objectives E-Government primarily focuses on the IT security objectives of confidentiality, authenticity, integrity, non-repudiation (binding character) and availability.

Life events Situations involving human beings that demand public services

Non-repudiation Guarantee that the sending and reception of data and information cannot be disputed. In other words, the property of non-repudiation relates to the confidentiality and proof of occurrence of a transaction.

Password Secret ID that protects data, computers, programs etc. against unauthorized access.

Portal A place where information (content and services) is being collected and shown to the citizen. The portal offers an interface to the information and possibilities to personalize the services

Public agency Any agency that performs public service tasks. The term is used more generally to refer to "government and public service".

Public Servant / Public Employee

A person working for the government.


Version V1.0 15.03.2004 - /93 -

Requirement/Functional Requirement

A system/software requirement that specifies a function that a system/software system or system/software component must be capable of performing. These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs.

Requirement/Non-functional requirement A software requirement (in software system engineering) that describes

not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively. IEEE-Standard 830 - 1993 lists 13 non-functional requirements: Performance requirements, Interface requirements, Operational requirements, Resource requirements, Verification requirements, Acceptance requirements, Documentation requirements, Security requirements, Portability requirements, Quality requirements, Reliability requirements, Maintainability requirements and Safety requirements.

Selection criterion Is a characterizing mark or trait on which a judgment or decision may be based.


Version V1.0 15.03.2004 - /93 -

Part I: Existing Knowledge


Version V1.0 15.03.2004 - /93 -

3 THE SITUATION OF PUBLIC SERVICE ACCESS

This chapter focuses on the current situation of e-Government in Latin America and Europe concentrating on the e-GOIA partner countries Brazil, Peru and Portugal. The needs and objectives of the transformation into a future electronic environment are described.

3.1 Brazil

3.1.1 Federal Situation

The Information Society Program, launched by Brazilian government in 2000, has as its goal to integrate, coordinate and foster actions for the utilization of ICT, in order to contribute to the social inclusion of all Brazilians in the new society and, at the same time, help the country’s economy secure the necessary conditions to compete on the global market. Among others, the program unfolds along the following broad Lines of Action:

• Universalization of services for citizens – promote the universal access to the Internet, pursuing alternative solutions based on new mechanisms and new means of communication; promote systems for collective or shared access to the Internet; as well as foster projects that encourage a greater sense of citizenship, national pride and social cohesion;

• Government at everyone’s reach – promote the computerization of government administration and the employment of standards in its applicable systems; create, prototype, and foster applications in government services, especially those that involve a wide dissemination of information; foster greater qualification in the management of ICT in government administration;

• R&D, key-technologies and applications – pinpoint the strategic technologies for industrial and economic development and promote R&D projects applied to these technologies in universities and in the productive sector; conceive and encourage the use of mechanisms of technological dissemination.

The green book of the Brazilian Information Society Program can be seen visiting the website: http://www.socinfo.org.br/livro_verde/ingles/index.htm.

To articulate and focus the different initiatives and projects providing universal access to services delivered by the government, an Electronic Government (e-Gov) Program was launched, under the leadership of the Presidency of the Republic. The e-Gov Program is coordinated through an interministerial committee and its main action plans include:

• To provide, through the Internet, all services rendered to the citizens, with improved quality standards, cost reduction and easy access;

• To promote convergence among governmental information systems, networks and databases;

• To broaden citizens access to information, in appropriate formats;

• To implement an advanced communications and service infrastructure;

• To make use of the Federal Government’s purchasing power on the procurement side;

• To encourage access to the Internet, mainly by means of public access points hosted by public, private and community institutions;

• To establish a legal and normative framework for electronic communications and transactions;

• To facilitate Internet access throughout Brazil.

More information about the e-GOV Program is available in Portuguese in the website http://www.governoeletronico.e.gov.br/.


Version V1.0 15.03.2004 - /93 -

3.1.2 Regional Situation

The creation of Citizen’s Services Centers (e.g. Poupatempo) in almost all the Brazilian states (nowadays 23 out of 27 existing States), which gather several agencies carrying out services from any area of the government in a unique space, has created a great advance on the answering of the demands of the civil society: initiatives which have contributed to improve significantly the image of the public service in Brazil.

Before these initiatives, the public services were considered archaic places, where dominated the image of bureaucracy, lack of information and explanations, bleak workplaces and services rendered with no respect and dignity to the citizen. Today, the Citizen’s Services Centers have been transformed in paradigms of efficiency, effectiveness and respect to the citizens’ rights not only for the public administration but also for the private sector.

However, the facility introduced by these Centers contributed to the performance of hundreds of services in a single space do not resolve the problems of the citizens presented by the specification of public services. Even when carried out in one single space, the citizens are required to present several times the same personal data and documents to the rendering of several services in these Centers. In its relationship with the government, the citizen assumes several conditions: as a driver, a worker, a family supporter, someone with criminal records, a taxpayer, a customer (of gas, electricity, etc). In other words, the rendering of each of these services depends on the database belonging to the different sectors of the public administration.

These sectarian databases, built more than three decades ago, cannot respond to the new demands placed by the civil society that, as mentioned above, require a new type of relationship with the State. That means the need of a new structure of databases and information, which has the ability of incorporating these new demands and functionalities.

The significant public resources applied in the legacy, the difficult rescue of memory of transactional rules (not systematized or scarce documentation, absence of the assigned database programmers, etc) and the complexity of requirements and the used logic require the decision of how to solve the use and updating of the legacy simultaneously aiming the new demands by the current administrators of these systems.

On the other hand, we should consider that 90% of the public services rendered in Brazil still require the citizen’s presence. The rendering of services by electronic means, also do not solve the mentioned fragmentation of the citizen in the several categories in which he/she is required to be submitted, according to the service carried out. On the contrary, the public sites reflect the division in sectors and similarly to the personal attendance mode, “force” the user to surf in several pages and to register several times the same demands to the rendering of the several services.

The great challenge presented in Brazil is the possibility of the construction of virtual citizen’s services centers, where it will be possible, by the integration of the legacy systems, the access to public services and information without the obligatory repeated certifications and where it will be possible to establish a new form of relationship between State and Citizen unlike the current fragmented one.

3.2 Peru

Governments are established to serve the people, to secure rights that they already have. The most important potential benefits of e-Government would be a more informed and empowered citizenry and a more accountable government.

Internet has the potential to empower citizens and foster a revolution in the relationship between citizens and their governments. In Peru, the Congress established a Web site that provides daily legislative agendas and the texts of bills before the Congress. Citizens are invited to comment on legislation under consideration. In addition, the UNDP has both helped establish the first computerized land-ownership registry in Latin America and helped produce a CD-ROM set which contains all Peru's


Version V1.0 15.03.2004 - /93 -

laws and is distributed free of charge country-wide to all judges and attorneys, including those in rural areas who cannot afford to maintain an updated legal library.

The Peruvian strategy in e-Government is based in four principal points:

• The citizen as the center of the process

• The improvement of the competitiveness in the country

• The modernization and transparency of the public management

• The international position of the country in e-Government

This strategy has focus on:

• Education and training

• Approaching to the citizen

• Regulation and norms

• Standardization and converge cement

• E-commerce

Nevertheless, Peruvian e-commerce is just barely in its infancy. Growth is predicted for the next several years, as in all of Latin America, but Peru still has major steps to take in order to truly make itself into an attractive market for electronic commerce opportunities, both as a market and as a provider. However, some government action has been taken, and there has been some domestic e-commerce developing in Peru.

3.3 Portugal

Portugal’s vision for e-Government was set out in The Green Book for an Information Society in Portugal, known as the Open State. The related program of action, Open State: Modernizing Public Administration was the basis for the foundation of Internet initiative announced by the Portuguese Government in 2000. Several initiatives were undertaken envisaging the growth in ICT access and usage in key fields of the national socio-economic environment, such as education, business and public administration.

The consolidation of the European Union approach to Information Society (IS), materialized in the approval of the eEurope Action Plans within the framework of the Lisbon Strategy, has induced significant changes in the Portuguese IS policy. It may now be considered a consistent policy area, as the former programmatic and institutional dispersion was replaced by an increasingly coherent and systematic approach.

In November 2002, IS policy development was entrusted to the Innovation and Knowledge Society Mission Unit (UMIC), strategically created within the Presidency of the Council of Ministers in order to ensure effective political leadership and inter-ministerial coordination and to CIIC – Inter-ministerial Commission for Innovation and Knowledge (Comissão Inter-ministerial para a Inovação e Conhecimento). A new Portuguese IS strategy was then approved, comprehending two action plans and three core specific programs:

• Information Society Action Plan

• e-Government Action Plan

• National Broadband Initiative

• National Program for the Participation of Citizens with Special Needs in the Information Society

• National e-Procurement Programme


Version V1.0 15.03.2004 - /93 -

This new strategy closely follows the guidelines of the eEurope 2005 Action Plan, as it aims to create the conditions for the development of applications and contents, and of safe online public and private services through widely available broadband infrastructures. In addition to these technological investments, Portugal is also focusing on human capital, as people, their qualifications and ICT skills are crucial for the sustainable development of an inclusive Information Society and of a Knowledge-based Economy.

In order to define the strategy for electronic government in Portugal where identified the following Critical Factors for the success of the electronic government development:

• Define a strategy focused on the citizen

o e-Government services should be oriented for the citizen, they must reflect citizen needs and not the public administration structure;

o Simplify the interactions with public entities;

o Built services easy to use and intuitive

o The services should be available in any moment and in any place.

• Act on the front-office and on the back-office

• Obtain more political and organization support

• Do strategic investments

• Adopt a collaborative approach

• Guarantee a civil society involvement and the development of the electronic democracy

• Define clear objective and participate on their implementation

• Define common technical standards and promote the interoperability

o Define interoperability commons standards;

• Celebrate private-public partnerships

o Increase the change of experiences between the public and private sector;

o Decrease the risk of the implementation of electronic government projects

• Implement CRM (customer relationship management) techniques on Public Administration Portals

o Allow the management of information and citizens profile;

o Offer personalized services according to specific needs of the citizens.

Key Players / stakeholders

As it was described before, UMIC - Innovation and Knowledge Society Mission Unit is the main responsible for the IS policy development. Below are presented a list of institutions that work together with UMIC:

• High Authority for Social Communication – AACS (http://www.aacs.pt)

• National Authority of Communications – ANACOM (http://www.anacom.pt)

• Government Management Center of Network - CEGER (http://www.ceger.gov.pt)

• Information Technologies Intersectorial Commission to Public Administration – CITIAP (http://www.citiap.gov.pt)

• National Commission for Data Protection – CNPD (http://www.cnpd.pt)

• DGITA (http://www.min-financas.pt/v30/Dgita/)

• Foundation to Information Technologies Promotion – FDTI (http://www.fdti.pt)

• Informatics Institute of Finance Ministry –II-MF (http://www.inst-informativa.pt/v20/)


Version V1.0 15.03.2004 - /93 -

• Information Technologies Institute on Justice – ITIJ (www.itij.mj.pt)

UMIC also includes two entities or programs:

• Observatory for Innovation and Knowledge – OIC;

• Accessibility to Citizens with Special Needs in Information Society – ACESSO (http://www.acesso.mct.pt).


Version V1.0 15.03.2004 - /93 -

4 E-GOVERNMENT SERVICES AND GOOD PRACTICE EXAMPLES

This chapter describes good practice e-Government factors and solution applicable to eGOIA based on partner experience and relevant knowledge that can be used to fulfill the objectives of eGOIA and the @LIS programme.

It commonly agreed that e-Government cannot be instantiated at once but is a long-term process that needs plenty of human and financial resources until it can be called final. To evaluate e-Government solutions and classify e-Government services it is very important to benchmark these services from a user/citizen point of view, despite the added value that also exists from the public administration point of view.

According to [2] the stages of e-Government can be classified as follows:

• Emerging: A government web presence is established through a few independent official sites. Information is limited, basic and static.

• Enhanced: Content and information is updated with greater regularity.

• Interactive: Users can download forms, contact officials, and make appointments and requests.

• Transactional: Users can actually pay for services or conduct financial transactions online.

• Seamless: Total integration of e-functions and services across administrative and departmental boundaries.

A re-engineering of public administration service-rendering processes is required in order to improve the cost/benefit ratio and the quality of all the services they deliver to citizens, professionals and businesses.

The actions and milestones to achieve a user-friendly e-Government are described in [3] and summarized below: • Increase the provision of on-line delivery of services;

• Foster the customization of services and generate best practice examples that will relate to the many ways of ensuring the quality of information offered by the public sector.

• Improve the management of the many internal re-organization processes needed;

• Increasing the e-Learning possibilities for staff;

• Improve the participation and consultation processes of citizens´ groups towards governments within the relevant regions;

To achieve these goals the eEurope2005 action plan of the European Commission [4] points out specific actions such as:

• Interactive services. Interactive services require the back-office reorganization and integration comprising the re-engineering of internal administrative processes that relate e.g. to data collection and data management, electronic information exchange, interagency co-ordination.

• Public Internet Access Points (PIAPs). All citizens should have easy access to PIAPs, preferably with broadband connections, in their communes/municipalities.

These specific actions are of particular importance for the eGOIA project, because they form the major technical goals of the project (back-office integration for the support of interactive services and front-office integration and instantiation of Citizen Points of Access (CPAs) as realization of the PIAPs.

The main user groups the eGOIA project targets are the citizens as well as public employees. The solution to be provided has to address their needs and has to provide added value compared to the traditional means of e-Government service usage.


Version V1.0 15.03.2004 - /93 -

Best practice factors to realize specific type of value are shown in Figure 2 [5]. eGOIA thereby concentrates on the user and employee values.

Figure 2: Best practice factors for e-Government projects

4.1 Brazil

4.1.1 Federal Good Practices

The Brazilian Government has placed a high priority on the adoption of advanced information communication technologies for its administrative processes and delivery of services to citizens. This has already produced remarkable achievements. For example, the Federal Government already offers a broad range of services through the Internet; most of them are available through the Redegoverno portal (http://www.redegoverno.gov.br), which includes more than 2,000 services and 20 thousand different categories of information. Some of the more notable services available to citizens over the Internet include:

• Filing income-tax returns (http://www.receita.fazenda.gov.br ⎯ in Portuguese);

• Issuing statements on the payment of taxes;

• Publicizing notices related to government procurement. The site http://www.comprasnet.gov.br (in Portuguese) offers access to all calls for federal governmental purchases. Besides the offered services, the process increases the business opportunities for Brazilian companies, wins speed and assurances transparency of the government purchases;

• Registering of governmental providers;


Version V1.0 15.03.2004 - /93 -

• Following-up court cases;

• Accessing economic and social indicators and census data. For example, the site http://www.obrasnet.gov.br (in Portuguese) publishes information on 20.000 constructions initiatives in execution included in the register of the Federal Savings Bank. The system has basic items of engineering that permit as parameter of comparison of the costs of the different constructions. Also, it allows the public administration to verify the liberation of resources in agreement with the established in contract or agreement.

• Delivering information on retirement and social-security benefits;

• Long-distance learning programs;

• Sending messages by mail, by means of public kiosks;

• Information on Federal Government programs. For example, the site (in Portuguese) http://www.assistenciasocial.gov.br/iframe/cadastro_unico/cadastro_unico.htm creates and maintains registers of families in situation of extreme poverty living in Brazilian municipalities so that the public administration can address and accomplish efficient and effective instruments for social politics.

Regarding points of access, the Federal Government, in agreement with city halls and non-governmental entities, will install 6 thousand citizens’ points of access up to 2007 aiming the digital inclusion. The first 31 community citizen points of access in 11 Brazilian states will be installed until April of this year. The action is a collective effort of the public and private organizations. There will be several points of access with ten computers each and support people for the population and kiosks. The initiative intends to reach about 60 thousand people a month, that today they are part of the group of millions of excluded Brazilians of the digital world. The users can have access to public services as payment of taxes, certificates, personal documents, fines, jobs, medical assistance, customer assistance, etc. They will also have access to the information, communication through community e-mail, school researches, entertainment and other benefits. The citizen will have free access to the digital world in those points of access. It is important to say that, in some places, the points of access will be the main contact with the world, as it is the case of the Pamáali School, in the municipality of São Gabriel da Cachoeira, inside the Amazon rainforest. There, the only access, going up Rio Negro, is by boat and it takes approximately two days going up the river. These initiatives use free software and are examples of actions to integrate projects of the federal, state and municipal governments aiming to promote the digital inclusion.

There are success cases in the Executive, Judiciary and in the Legislative:

• The elections processes are totally electronic executed, where more than 100 million voters can express their will using voting machines and seeing the results (partials and final) on the Internet. Site in Portuguese http://www1.tse.gov.br/ .

• The Interlegis Network links the local, state and federal legislative houses for information exchange and publishing their information on the Internet stimulating transparency. Site in Portuguese http://www.interlegis.gov.br/ .

4.1.2 São Paulo State Good Practices

The “Rede do Saber” (“Knowledge Network”) using a complex infrastructure of communication assured the university graduation of 7000 teachers of public schools of the State of São Paulo. It used the videoconference tools and electronic collaboration forming an e-learning network in 89 localities. Today this network is used to update the skills of public servants (G2E).

The “Bolsa Eletrônica de Compras” (“Electronic Auction”), created to purchase assets revolutionized the way the Government does its business transactions with about 40.000 items registered the Government is saving 17%. It has been in process since 2000. Similarly, since the beginning of this year, the electronic auction has been an alternative for the acquisition of assets and services offering a fast, dynamic and economic process. This modality of purchasing allows the free negotiation between government and suppliers (G2C).


Version V1.0 15.03.2004 - /93 -

The “Electronic Report of Criminal Occurrences” has brought to the citizen the reduction of bureaucracy, as well as the speed, allowing the citizen to report determined occurrences to a virtual electronic police station such as loss of documents, thefts, etc (G2C).

According to a recent survey, only 2% of the Brazilian population has access to Internet. In order to minimize this problem, programs of digital inclusion have proliferated in the country. Excellent examples are the “Navegar” (“Navigating”) project: a boat where computers were installed to navigate in the Brazilian rivers to reach the cities along them and provide Internet access to poor communities.

Similarly, the “Access São Paulo” project provides 134 public points of access, with no cost to the population. It has a network of about 10 PCs offering access to the Internet with ADSL connection. These points of access were built in partnership with community centers and municipalities. Numerous initiatives used buses and trucks, like the “Navegar” project, proliferated in the country. All these initiatives aim not only the digital inclusion, but also the social inclusion of the population.

In order to integrate the information of the Government as well to supply the mechanisms that allow the effective management of the resources, the Strategic Information Systems Department, formed by 61 applications accessed through 20.000 workstations interconnected by a high-speed network. As a result of that, the public administrators have already saved US$ 2.5 billion in the last 7 years using only one of the 61 enforcements. For example, the Outsourcing Services Register supplies a single register with information related to outsourced contracts, such as the usual price, the latest acquisitions, measure unit’s standards, etc. Thus, the administrator before contracting a determined service acquires essential information for the negotiation.

In the State of São Paulo, there are 12 million of vehicles whose control has been implemented electronically allowing the citizen to renew his/her annual documents, pay his/her taxes and fines directly by the Internet, and receive the updated documents directly to his/her residence.

The demand for the public services offered electronically has increased and in order to supply it, numerous electronic citizen service centers throughout Brazil have been created according to the e-Poupatempo model. These centers aim the simplification of procedures to obtain the services as well as the direct access of the citizens.

4.2 Peru

The Registry Information System (SIR) is a system deployed across the bureaus of Peru’s National Superintendent of Public Registries (SUNARP). The Registry Information System and the consequent online registry publicity service give information of all public registries that exist in Peru. Although, SUNARP faced challenges to implement the system such as the digitalization of all the documents prior to the digitalization of the system, and make their workers comfortable with the new system, the service is nowadays available to the citizens.

SUNARP is the only place one can verify the legal status of property, including businesses, homes and personal estates. Historically, getting the required information in less than three to four weeks had been impossible. But thanks to SUNARP new website, a document is available with the touch of a computer key. Any citizen can access to the registered information using the web page and paying online for the service.

The System of Automatic Acquisitions and Contracts for the Peruvian Government (SEACE) is an Internet-based solution intended to improve the acquisition processes in the government. It links public institutions interested in buying related goods or services to private companies that could offer these services. Practically speaking, the system is a Web Site with mechanism that will allow to any public institution the following:

• To make public the annual budget of acquisitions and contracts signed up with private institutions.

• To publish specific requests for products, services or a combination of both.

• To receive fees and exchange information with sellers.


Version V1.0 15.03.2004 - /93 -

This system helps to reduce complex, paper-based transactions among public institutions and sellers and aim to improve purchase order efficiency. Moreover, it will help the government decrease related operating costs.

ONPE is developing its Automated Voting System, which is aimed to allow citizens to vote by electronic means. The system is in an early stage of development and it has been proved on the internal elections of a local political party. By now, the system works on local area networks only. The main task is to deploy it as a web - based system. According to ONPE, the system will be implemented gradually on the next three General Elections starting in 2006.

4.3 Germany - Berlin

The aim of the project VeZuDa was to develop and to implement a concept for back-office integration to overcome the missing access to data and information in the Berlin City Administration. The large areas of stored data, separated and managed by different administrative units had to be made available inside the Berlin City Administration, as long as this is technically possible and legally allowed. Additionally a modernized IT-infrastructure had to be installed to support development and implementation of services faster and easier. Re-use of services or components of services was one of the main requirements within the project. The VeZuDa architecture and back-office integration concept is of major importance for the eGOIA project and it is therefore described in detail in the Annex A.1.

BLIS is a service of the Berlin City Administration built on the concepts and technical results of the VeZuDa project. BLIS offers access geospatial data of real estate affairs, information about ownership, regional development plans and cost overviews. This service fulfils two functions, on the one hand the integration of distributed available data and the combination of therein contained information and on the other hand the provision of a user-friendly portal with intelligent search and application functions making BLIS a value added information service. The BLIS project is an example of a successful back-office integration based on VeZuDa and is therefore described in detail in the Annex A.2.

An information system – Start-Infosystem – has been realized in Berlin (1996-2002) that allows simplification and speeding up of administrative processes as front-office public employee work places in more than 60 Berlin citizen offices. This system will be available at more than 1.000 workstations. The objective of this solution is that all administrative processes and standard forms, as well the automation of the collection of municipal fees, will be available online via a standardized information pool. The public employee is able to assist the citizen in his life-situation (such as child-is-born, movement, marriage, etc) by giving a step-by-step information/advice on what to do, including the relevant forms and initiating the actions. If a citizen is missing some official documents he needs for his request he does not need to go back to his “original” office but can use any office in Berlin. “His” personal administrative process is available in all offices. Start-Infosystem is not connected directly to all back-office services but serves as guidance tool through public administration services and provides a physical one-stop-shop.

The Discourse Support System Zeno is an Open Source groupware application for the Web written in Java, which has been designed specifically for use as a discourse support system. This includes managing both the communities of users and groups who participate in the discourses and the content that is created and used in the discourses. A simple but powerful role-based access control scheme connects the two functional parts of ZENO: users and groups managed by the directory service are assigned access roles in journals where the content of discourses is stored. Discourse management functions for session management and event monitoring (logging, notification, discourse awareness, etc.) as well as communication services (messages to users and journals) provide the necessary support during a discourse. ZENO’s features are implemented in an extensible, object-oriented system architecture with easily customizable user interfaces, using the Velocity template engine and Cascaded Style Sheets.

One of the many successful applications of the Zeno was the use as a part of the foundation of the DEMOS system (http://demos-project.org). DEMOS stands for Delphi Mediation Online System and was an e-democracy research and development project founded by the European Commission (IST-


Version V1.0 15.03.2004 - /93 -

1999-20530). The DEMOS system offers innovative Internet services facilitating democratic discussions and participative public opinion formation. The main goal is to reduce the distance between citizens and the political institutions by providing a system for moderated discourses involving thousands of participants about political issues at the local, national and European level. The vision of DEMOS is to motivate and enable all citizens to participate actively and effectively in political processes. On this way these processes become more democratic and more efficient than current practice.

4.4 Portugal

Portugal has a solid base of services developed around the intentions of citizens, especially in the regulation sector.

One example of that service is the registry agency Direcção Geral dos Registos e do Notariado website, http://www.dgrn.mj.pt. This service allows citizens to:

• Request a copy of a birth or death certificate online;

• Registration of a new company;

• Other services related to consultancy of National Legislation

An overview of actual available services can be found at:

• Portugal’s public services portal (INFOCID - Portal da Administração Pública Portuguesa) - http://www.infocid.pt/; This portal offers the following services: On-line simulation for taxes; electronic declarations of taxes; information about taxes; information about government; Social Security Salaries Declarations forms; Social Security requirements and declarations forms; information about European Union;

• Presidency of the Council of Ministers - Unit of Innovation and Knowledge (UMIC - Unidade de Missão Inovação e Conhecimento) - http://www.umic.pcm.gov.pt/UMIC

• Access to Social Security Services - http://www.seg-social.pt

• Present a claim on Ministry of Justice - www.mj.gov.pt

• Health Ministry displays information’s related to Pharmacies, blade information and other information to citizens – www.min-saude.pt

Although relevant to citizens, the organization of Portugal’s public services portal does not address the most common user intentions, such as finding the closest hospital or paying a parking ticket, and remains focused on government agency structures.

The Site Diário da República (http://wwwwww.dr.incm.pt/dr/default.asp) can be accessed in two ways: free access and access for registered members. Using free access the user can consult by year, number, publication date, etc. some articles published by the Official Journal. The registered users get a registration number and a password. This allows them to receive electronic message interesting news corresponding to his domain knowledge. The client pays an amount to have a registration.

In line with many other countries in this research, to date Portugal’s strengths lie in the Revenue and Postal sectors, with a number of sites delivering services at Transact level. For example, citizens can send electronic mail on the postal service CTT Correios website, http://www.telepost.ctt.pt, and businesses can submit their income and VAT forms on the Taxation Department website, http://www.dgci.min-financas.pt.

There are a number of encouraging projects in the pipeline, for example, the employment agency Instituto do Emprego e Formação Profissional website http://www.iefp.pt, plans to introduce a range of employment related services for citizens such as job search and eLearning applications.


Version V1.0 15.03.2004 - /93 -

5 FRAMEWORKS, ARCHITECTURES, STANDARDS AND INITIATIVES

Architectures for IT in public administration must consider and take into account the specific situation of adopting systems that already exist and being operated – evolutionary vs. revolutionary IT concepts and IT strategy.

Below the specific concern of Brazil is outlined and the basic approaches in Europe towards a global e-Government framework and standardized approach is described.

5.1 Brazil

Brazil has lacked effective long-term policies, regarding e-Government architecture, standards and reference models. The Public Key Infrastructure and the Brazilian Payment System are initiatives towards an e-Government framework and standardized approach.

5.1.1 Public Key Infrastructure

The Federal Government is developing policies for the secure authentication and management of information, which includes putting into place standards and enabling legislation for electronic certification and authentication, including a public key infrastructure (PKI) framework called ICP-Brazil.

As in other countries, there is a general view that authentication technologies require the enabling hand of appropriate legislation. One goal is to remove any existing legal obstacles to the recognition of electronic signatures and records and to ensure that electronic signatures and records fulfill existing legal requirement for signatures or transactions. Another objective is to establish a legal framework for the operation of a Brazilian PKI - an area where countries have taken broadly different national approaches. The Brazilian Government’s position is that, in order to facilitate the adoption and use of asymmetric cryptography as well as to ensure the national public interest, appropriate legislation is required and a great deal of legislative activity is taking place in this domain. The umbrella framework policy on government information security is defined in a Presidential Decree dating from June 2000. More specifically, the interim arrangements for a Brazilian Public Key Infrastructure -- ICP-Brazil, where the Information Technology National Institute (ITI – http://www.iti.gov.br/) manages the Root Certificate Authority, are defined in Provisional Law No 2.200-2, adopted in August 2001. A Presidential Decree from October 2001 further requires that Federal bodies must use ICP-Brazil for the purposes of digital certificates and in the context of the exchange of encrypted and digitally signed documents. A long-term goal is that to all Brazilian citizens digital certificates will be issued, which will also be used to access personalized government services.

5.1.2 Brazilian Payment System

The Brazilian PKI provides integral support to the new Brazilian Payment System (SPB), which was deployed in April 2002. This is a closed system among approximately 180 Brazil financial institutions, which allows banks to automatically deposit funds and have those funds available immediately, as well as to promptly check and approve deposits among other Brazilian banks. Compliance certification is handled by the Brazil Central Bank, which will guarantee the authenticity of other banks through the use of digital certificates.

The Brazil Payment System is an important component of a planned electronic payment scheme for Brazilian citizens, a near-term goal of the Electronic Government Program. This will put in place a government service for the receipt of electronic payments of fees, taxes, contributions, real-estate transfer fees and others, allowing the delivery, through the Internet, of the full cycle of services to citizens.


Version V1.0 15.03.2004 - /93 -

5.2 European Union

EU leaders at Seville launched the eEurope 2005 Action Plan in June 2002. It sets out the targets to be achieved by between 2003 and 2005 to promote the development of a knowledge-based economy in Europe. Various Programmes were initiated to achieve this goal. One of the initiatives is IDA (Interchange of Data between Administrations), which is described below.

5.2.1 eEurope 2005 Action Plan

Public services are expected to become more user-friendly and personalized and adapted to the needs of individuals. Public services generally need to be inclusive, i.e. all citizens need to be served, independently of their skills and capabilities, income or geographical location.

The eEurope 2005 Action Plan [4] that succeeded to eEurope 2002 sets the following targets:

• Interactive public services: By end 2004, should be ensured that basic public services are interactive and accessible for all. The Commission and Member States agreed on a list of public services (that is presented below) for which interactivity and interoperability are desirable. Relevant issues include exploiting the potential of broadband networks and multi-platform access, and addressing access for people with special needs;

• Public procurement: By end 2005 a significant part of public procurement should be carry out electronically contributing for cutting costs and raising efficiency in government procurement;

• Public Internet Access Points (PIAPs): All citizens should have easy access to PIAPs, preferably with broadband connections, in their communes/municipalities;

• Broadband connections: Member States should aim to have broadband connections for all public administrations by 2005. Authorities should not discriminate between technologies when purchasing connections;

• Interoperability: The Commission intends to present an European interoperability framework for pan-European e-Government services;

• Secure communications between public services: The Commission and Member States will examine the possibilities to establish a secure communications environment for the exchange of classified government information.

5.2.2 IDA Initiative

IDA (Interchange of Data between Administrations) [6] is a European Commission driven strategic initiative using advances in information and communications technology to support rapid electronic exchange of information between EU Member State administrations. The objective is to improve Community decision-making, facilitate operation of the internal market and accelerate policy implementation.

The IDA mission is to support the implementation of Community policies and activities by coordinating the establishment of Trans-European telematic networks between administrations. As data needs to be exchanged throughout Europe, IDA also acts as an important vehicle for the re-engineering of the working processes of the administrations. The work within IDA is performed through several action lines: Promoting the implementation of sectorial networks in priority areas of work


Version V1.0 15.03.2004 - /93 -

1. Developing interoperability measures, for use by sectorial networks

2. Extending the benefits of the networks to Community industry and citizens

3. Co-operating with national authorities and

4. Co-operating with other EC services.

The IDA Programme is set to become the IDAbc Programme (Interoperable Delivery of pan-European e-Government Services to Public Administrations, Businesses and Citizens) in 2005.

In June 2002, European heads of state adopted the eEurope Action Plan 2005 at the Seville summit. It calls on the European Commission “to issue an agreed interoperability framework to support the delivery of pan-European e-Government services to citizens and enterprises. It will address information content and recommend technical policies and specifications for joining up public administration information systems across the EU. It will be based on open standards and encourage the use of open source software.” The European Interoperability Framework (EIF) is to support the pan-European delivery of electronic government services. A new working draft of EIF (January 2004) is available [7].

5.3 Germany – BundOnline2005 Program

BundOnline2005 [9] is the e-Government program of the German government announced on 18 September 2000 by the Federal Chancellor. The free objective of the program is to have 2005 all Internet-capable services of the federal administration on-line available.

5.3.1 Standards and Architectures for e-Government Applications (SAGA)

The German “Standards and Architectures for e-Government Applications (SAGA)” [10] is published by the German Federal Ministry of the Interior. It provides the recommendations for the implementation of interoperable e-Government systems and services based on international standards. The document presents standards, processes, methods and products of state-of-the-art IT development for e-Government applications in a concise form.

SAGA is primarily designed for decision-makers in the fields of organization and information technology (e-Government teams) in German administrations. The document is a guideline that serves as an orientation aid when it comes to developing concepts for technical architectures and general technical concepts for individual IT applications.

SAGA is not a fixed document but a work in progress that is constantly updated. The latest developments and findings in relation to standards and architectures for e-Government applications are regularly integrated into the document. The Federal Ministry of the Interior has set up an expert group that includes representatives from industry and federal offices and selects their members. In addition, comments posted in the public SAGA forum are evaluated and integrated into document updates.

SAGA is a full-scale standardization approach that focuses on four development directions (tasks) as follows:

• The definition of technical normative references, standards and architectures: The technical standards and architectures cover all the levels and components relevant for e-Government. They are the basis for interoperability and compatibility during the development of e-Government applications and the basic components of the BundOnline 2005 initiative.

• Process modeling:


Version V1.0 15.03.2004 - /93 -

Process modeling means the methodical description of the e-Government processes as a whole or in partial steps in order to: (1) Achieve a similar and comparable design and layout of the different applications; (2) Ensure a high degree of re-usability of processes and systems.

• Data modeling: Data modeling means the methodologically standardized description of the data communicated within the scope of e-Government processes (applications) as a whole or in part in order to: (1) Ensure the interoperability of different, even future applications; (2) Ensure a high degree of re-usability of processes and systems.

• The development of basic components: Basic components are selected, specified and implemented by BundOnline 2005 on the basis of frequently used, general process models. Six basic components have already entered into the implementation phase.

The „Basic Components“ in the German e-Government architecture are for realizing, providing and where appropriate developing central functionalities that can be planned and used by central implementation teams. These components offer central technical functionalities that can be integrated into the various services. A major characteristic of the basic components lies in their provision of supporting services.

The Basic Component Data Security is described with more detail in Figure 3.

Figure 3: Overview of the Basic Components for e-Government in German SAGA

In order to be able to develop secure, legally binding electronic communication over the German Information Security Agency is developing the “Basic Component Data Security – the Virtual Post Room“ for use by all public authorities in Germany. In electronic communication the virtual post room will function largely automatically as a central gateway that provides diverse security functions such as authentication (based on electronic signatures), signature creation (for e-Government employees) and validation, decryption and encryption, and additional security checking functions (e.g. time-stamps, virus checking etc.). As access channels two technical communication means are foreseen: e-mail (e-mail with or without attachment) and Web interfaces (e.g. forms). If for confidentiality reasons the data processing by the virtual post room is not acceptable also end-to-end communication is supported, i.e. the virtual post room does not process the data but passes it through to its final destination. All security functionality has to be executed then by the recipient. If needed, receipts can be created and sent to the sender. The design of the virtual post room is based on the design and experiences with


Version V1.0 15.03.2004 - /93 -

OSCI (see below, whereby OSCI originally did not include the e-mail access to services/public agencies).

The virtual post room is not a workflow component and not a middleware-replacing application server. It aims to be as simple as possible and it is meant to support the handling of signatures and the associated certificates validation to relieve the employees of performing all the security related actions (such as the handling of smart cards, signature validation and generation, encryption/decryption, key management, updating of virus checkers, generation of time-stamps etc.).

5.3.2 Dedicated Standard for Secure e-Government Transactions - OSCI

OSCI (Online Service Computer Interface) [12] and [13] is a two-layered protocol, developed by Bremen Online Services and now a mandatory standard in German SAGA and also integrated in the IDA eLink Specification of the European Commission [6]. The main goal was to build a secure and reliable infrastructure for highly automated as well as transactional processes especially for e-Government. OSCI is based on international standards such as SOAP, XML Signature and XML Encryption. OSCI is an open standard, which is available free of charge and also in English language. The portal of Bremen (based on OSCI) won the eEurope award for e-Government 2003 in Category 1: „The Role of e-Government for European Competitiveness“.

OSCI™ Version 1.2 was finalized in June 2002 and consists of two parts:

• Part A: OSCI Transport – containing the security and communication functions

• Part B: Specific e-Government application data structures and process models (currently XMeld – for the registration of citizens in Germany); Additional Xxyz are planned.

OSCI-Transport 1.2

OSCI-Transport is a transaction oriented communication protocol with enhanced security features. Communication between a sender and a receiver can be synchronous or asynchronous thus allowing different communication patterns.

OSCI differentiates between content data and utilization data. Content data is confidentially transmitted between the sender and the receiver. Only the authorized receiver is able to read the content. The utilization data is used to handle secure e-Government transactions. A routing slip has therefore been introduced as an integral part of the utilization data.

The routing slip:

• Controls the processing of the message to the intermediary

• Defines the message modalities (also the data structures for timestamps) and the use of the intermediary's surplus-value services

• Is generated exclusively by the user and updated by the intermediary while processing the message.

Using the routing slip, the intermediary confirms by signature to the sender or recipient that he has sent, or received OSCI content data - and includes the date of delivery. An electronic signature guarantees integrity and authenticity of the transported OSCI data.

OSCI Data Format

The data-exchange format of OSCI is based on XML. The data structure is a well-designed XML document and valid with respect to the given XML format. Electronic signatures applied to these XML documents are based on the W3C XML Signature Standard.

OSCI Infrastructure


Version V1.0 15.03.2004 - /93 -

The OSCI infrastructure is based on the following main components:

• OSCI kernels encapsulate basic application-independent functions in particular in the fields of security and transport

• OSCI applications perform individual applications and generate OSCI messages. They send them to the kernel for visualization, signature, encoding and transmission

• OSCI intermediary is located between a sender and a receiver and produces surplus value services without any loss of confidentiality

• Backend adapters integrate the special procedures existing in public administration into the OSCI infrastructure and thereby enable continued processing without any interruption in the media.

The intermediary

The central mediating function, the so-called intermediary, can provide surplus-value services without risking confidence on the business-transaction data level. The intermediary does not gain any knowledge of the transported OSCI data content, i.e. data concerning the respective business transaction.

The intermediary performs the following tasks:

• Information is saved securely in an intermediate storage and only transmitted to authorized persons.

• Cryptographic functions that are cost and time-consuming can be centralized.

• The intermediary can check message delivery regulations.

Security objectives of OSCI

The following security objectives are supported by OSCI:

• Confidentiality: OSCI guarantees both the confidential transmission of the messages and their confidential storage with the intermediary. The intermediary does not gain any knowledge of the transported OSCI data content either, i.e. data concerning the respective business transaction.

• Integrity and authenticity: An electronic signature guarantees the integrity and authenticity of the transported OSCI data.

• Obligation: Using the routing slip, the intermediary confirms by signature to the sender or recipient that he has sent, or received OSCI information data - and includes the date of delivery.

5.3.3 e-Government Manual

Although there are advantages in using IT widely and in using the Internet to exchange information with the public and with companies, there are also a number of associated security risks. Appropriate security measures such as encryption, electronic signatures and firewalls are needed. For many public agencies, e-Government represents virgin territory. BSI has therefore supported the BundOnline initiative by publishing the e-Government Manual. All the important themes, like information about organization and use of IT in e-Government or recommendations on technical aspects of security, are provided in particular. At the same time, it is hoped that broad acceptance of these recommendations will result in selected security mechanisms becoming widespread, which will promote interoperability and check the flood of different protocols and standards.


Version V1.0 15.03.2004 - /93 -

5.4 United Kingdom – e-GIF

The UK GovTalk consultation processes [14] sets the technical standards that support information to flow seamlessly across the public sector to provide citizens and business with better access to government services. It covers 6 areas: Gateway, e-Government Interoperability Framework, XML Schemas, e-Government Metadata Standard, Government Category List and e-Services Framework.

The e-Government Interoperability Framework (e-GIF) [14] addresses mandatory specifications and policies to adopt the Internet and World Wide Web specifications for all government systems in the UK. The e-GIF Framework defines the technical policies and specifications governing information flows across government and the public sector. The key policies within the framework focus on activities such as Internet and Web Standards and browser interfaces for access. There is a strategic decision to adopt XML and XSL as the core standards for data integration and management of presentational data. This includes the definition and central provision of XML schemas for use throughout the UK public sector to reduce the costs and risks of developing data interchange systems.

The e-GIF covers interconnectivity, data integration, e-services access and content management. Version 5 is in two parts:

• Part 1: Framework. Contains the high-level policy statements, management, implementation and compliance regimes.

• Part 2: Technical policies and specifications. Contains the technical policies and tables of specifications, a glossary and abbreviations list.

At the highest level complying with the e-GIF means in the UK:

• Providing a browser interface for access

• Using XML as the primary means for data integration

• Using Internet and World Wide Web standards

• Using metadata for content management.

e-GIF contains a “Security Framework“ for the expression of security requirements for the procurement and acceptance of e-Government services and their implementation. The security framework is accompanied with specific frameworks and guidelines such as for registration and authentication, confidentiality, trust services, assurance and security architecture [16].

5.5 USA - FEA

Within e-GOV activities, the USA OMB’s Federal Enterprise Architecture Program Management Office (FEAPMO) [17] has continuing stewardship responsibilities for the E-GOV Initiatives (www.feapmo.gov). This is part of the FEAPMO’s larger role in defining a Federal Enterprise Architecture (FEA) - a function-driven framework for describing the business operations of the Federal Government independent of the Agencies that perform them.

The purpose of this effort is to identify opportunities to simplify processes and unify work across the agencies and within the lines of business of the US Federal Government. The outcome of this effort will be a more citizen-centered, customer-focused government that maximizes technology investments to better achieve mission outcomes. The FEA is a business-based framework for cross-agency, federal government-wide improvement.

The FEA provides a consistent, industry-aligned architecture for definition of and communication about the components commonly needed to deliver E-GOV solutions.

A more detailed introduction into FEA can be found in section B.2.


Version V1.0 15.03.2004 - /93 -

PART II: General Requirements and Constraints


Version V1.0 15.03.2004 - /93 -

6 GENERIC EGOIA DEMONSTRATOR REQUIREMENTS AND CONSTRAINTS

This chapter identifies eGOIA demonstrator requirements comprising the different needs, constraints and organizational information of the target environment with respect to social, organizational, technical, political, financial, economical, security aspects and others. The interests of the eGOIA user groups such as citizens, employees of the public administration, administrators, etc are of major importance.

6.1 Requirements Engineering Process

The requirements of a system are the result of the requirements engineering process [8], which is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Figure 4 visualizes the requirements engineering process [8].

Agreedrequirements

Systemspecification

Systemmodels

Requirementsengineering process

Stakeholderneeds

Organisationalstandards

Domaininformation

Regulations

Existingsystems

information

Figure 4: Requirements engineering process

In a complex system that involves a variety of stakeholders, resources, systems and services with different requirements onto the final system a viewpoint-oriented approach is useful [8] with the advantage of

• To explicitly recognize the diversity of sources of requirements

• To provide a mechanism for organizing and structuring this diverse information

• To impart a sense of thoroughness (completeness)

• To provide a means for requirements sources or stakeholders to identify and check their contribution to the requirements.

6.2 Stakeholder Requirements

Stakeholders are the people involved in the design, implementation, deployment and usage of a system. The eGOIA projects concentrates on two user groups: the citizen and the public administration employee (as an user in G2G environments and as the operator of the system), both essential to verify the usability and success of the final demonstrator.

6.2.1 Citizen Needs


Version V1.0 15.03.2004 - /93 -

The eGOIA Demonstrator must provide to the citizens (Brazil and Peru) efficient public services of good quality. The use of modern Internet technology is regarded as a technology to support citizens’ daily business with the public administration such that it becomes easier and quicker. This is the main goal of this project:

The requirements gathered from the citizen viewpoint are the following:

• Minimize the physical presence of the citizen Citizens want the ability to access services from home, work or any other geographic location. The physical presence of the citizen at the local administration offices should be avoided whenever possible.

• Simple access to (complex) public administration services The citizen should not need to know the different administrative units involved in the performance of a selected service, i.e. no knowledge of organizational structures and physical localizations is required.

• Access by a user-friendly Web portal The online access to e-Government services must be simple and user-friendly enough to encourage also non-experienced users to access and use this new technology. This implies that a high level of success in learning is required.

• Comfort and practicability Services must be offered in an intelligent and comfortable way to the users. This includes information about the service processing stage, the estimated date to be concluded and a wide variety of possibilities of physical places to be chosen as pick-up places for documents and certifications ordered in an electronic way.

• Electronic payment of services The means of electronic payment of services are desirable such that the citizen will have the option to pay the public taxes and fees in more practical way.

• Variety of user end-systems Users don’t want any limitation on how they can access public services, whether by PC, hand-held, WebTV, mobile phone or any other wireless device. Access to public services should provide for different access means in the future.

• Variety of access methods Citizens need a great variety of communication channels including ways to authenticate them. The most common communication channels are: Internet, letters, fax, e-mails, phone, face-to-face, call centers, kiosks, etc. Often those most in need of government services are those least likely to have access to the Web. Rural areas, with less likelihood of having high-performance technologies such as ISDN or cable modems, are at a disadvantage, as are lower-income households, grassroots community organizations, and small businesses that often lack direct access. While Internet access through schools, libraries, or other public places is increasingly available, people without direct access remain at a disadvantage compared to the connected minority. Given this uneven distribution of access to the Web, traditional service delivery through telephone, mail, and face-to-face interactions is needed in parallel also in the future.

• Non-stop service offer It is important to guarantee at least some electronic communications channels opened 24hs, 7 days a week for the population.

• Consistency The citizen must not have the feeling that its profile is spread in the government entities.

• Multiple language support To reach a great diversity of the public, including tourists and naturalized citizens that are unable to understand the official natural language, should be able to use another language. The languages to be supported are: Portuguese, Spanish and English.


Version V1.0 15.03.2004 - /93 -

• Proactive government Most of the time the citizen will access the administration portal not to execute a specific service, but in a passive way, to get information about what to do. Therefore, the services must be provided in a proactive way on the part of the administration, always informing the citizen about pending situations and scheduling future public events and obligations. In this sense, there must be more than one communication channels to improve the probability that the citizen will be really informed.

• Service confirmation The citizen must have an affirmation that the service was initiated and/or fulfilled.

• Participation in democratic processes To foster e-inclusion it is desirable to support the democratic participation of citizens in political processes through the e-Government portal, e.g. to vote and express opinions about specific topics.

6.2.2 Civil Servant Needs

Besides the citizens also the civil servants / administrative employees are directly influenced by the new developments towards electronic access and execution of public services. There are diverse requirements also from their point of view:

• New paradigm Civil servants need to be trained to handle new paradigm: from bureaucracy-centered to citizen-centered government. A new understanding of administrative services focusing on customer orientation is required.

• Knowledge management An Intranet information platform has to enable employees to access necessary information in a simple and fast way. Knowledge management leads to better cooperation and continuing education.

• Civil servant participation Participation and possibility for employees to state their own opinion about requirements and information made available.

6.3 Organizational and Domain Requirements

A set of requirements is imposed by the organization (public administration) and the business domain (e-Government). These requirements may be constraints that influence the system and restrict certain technological choices. For design, deployment and acceptance of the eGOIA demonstrator these requirements/constraints have to be refined according the final decision on the services to be demonstrated.

6.3.1 Organizational Requirements

6.3.1.1 Administration

• New paradigm: from bureaucracy-centered to citizen-centered government;

• Optimization of internal and external business processes;

• New understanding of administrative services, focus on citizen orientation;

• Single point of access to e-services and information offered by different public administrative units;

• Well-defined online-strategy.


Version V1.0 15.03.2004 - /93 -

6.3.1.2 Administrative units

In dependence on the services selected for demonstrations, constraints and policies of the involved administrative units have to be clearly identified (e.g. internal security mechanisms such as electronic signatures and firewalls), regulations and consistency rules according to its policy.

Possible difficulties that arise from the participation of more than one administrative unit in the service provisioning have to be identified.

6.3.1.3 Employee acceptance

It is important to promote the challenges and achievements of the new technology to the employees of the public administration. This includes the continuing education of the personal to eliminate acceptance barriers.

6.3.2 Financial Constraints

Regarding the requirements of the desirable technical solution of the system there exists a trade-off with the financial constraints (available budget) that have to be considered. This includes:

• Investment (incl. time periodic)

• Orderly costs, incl. training, etc

• Contingency costs

Financial constraints may play a major role. Considering constraints and external conditions for planning, developing, building and running an e-Government system, it should be clear – and carefully distinguished – that there are qualitative as well as quantitative effects.

6.3.3 Ownership and Intellectual Property Rights

Ownership of databases and data imposes constraints on

• Accessibility and transmission of data

• Data (database) integration

• Maintenance and administration of data (databases)

• Guaranties of the right of knowledge and correction of personal data etc.

6.3.4 Legacy Systems and Legacy Databases

Since specific legacy systems can only be taken into account if specific e-Government services are chosen for demonstration (task of Subproject 3) only the following general aspects can be considered, such as:

• Commercial policy related to data.

• Commercial constraints related to suppliers agreements (such as system licenses etc.)

• Infrastructure required by the legacy system


Version V1.0 15.03.2004 - /93 -

6.3.5 Physical Infrastructure

Available infrastructure has to be identified and taken into account, such as to identify missing components in time.

6.3.6 Observation of Current Developments

Programs, projects, future developments on national level might actively or passively influence the eGOIA demonstrator. Especially legal and supportive actions have to be constantly observed.

6.3.7 Dissemination Constraints

6.3.7.1 Portugal

The e-Government strategy implementation is limited due to some difficulties (factors/barriers) that Portuguese government is trying to reduce. Below there is a list of factors/barriers:

• Lower penetration of Internet in the geographical area;

• Limited service availability – The availability of the services is improved if there are available through a large number of devices, including PC, digital TV, mobile terminal, or public Internet access points, alongside the usual physical, offline service provision.

• Lack of user-friendly access for people with disabilities or less IT-literacy - Education and training are essential to ensure that citizens have the necessary digital literacy to be able to take full advantage of the services offered by e-Government. Digital literacy is one of the priorities of the new eLearning Programme.

• Trust and Confidence – There are issues where public services should never fail, namely protection of personal data, authentication and identity management. The digital transactions and communications are secure and the personal data will always remain protected.

• Changes in administrative structures – The major advantages of the e-Government are achieved with a true integration between the front end and the back office systems. This requires changes in administrative structures, development of new skills and redesign of processes. Only with the implementation of the necessary changes is possible to truly capture the benefits of e-Government.

• Accessibility – In order to achieve the purposed objectives, the services developed in e-Government strategy should be conceived with special attention to citizens with special needs.

6.4 Regulations and Legal Requirements

Regulations and laws are boundaries for the eGOIA project that have to be examined and respected.

• Electronic signatures Constraints concerning registration and authentication laws and regulation; Brazilian legislation related to electronic signature (MP 2.200 / 2001).

• Security and privacy Law and regulation status and tendencies in short term in Brazil (in particular, Brazilian Senate Bill Nr. 3.494/2000, about structure and use of data banks); Constraints for data transmission and data bank integration concerning privacy rights; Access restrictions on highly sensitive data with very high protection requirement: such as race data, political and religious opinions, police records etc. Access restrictions regarding the public accessibility of data bases;


Version V1.0 15.03.2004 - /93 -

Limited access to data, e.g. access only by organizations, public or private, for the original service (purposes of the databanks) Data integrity and confidentiality securing the intentional or unintentional access, modification or destruction of personal data;

In dependence on the services chosen for demonstrations it has to be checked if there exist requirements on e.g. digital signature, constraints regarding personal presence of citizens at the office, paper-based instead of electronic documentation or collaboration regarding different administrations.

For Peru is required legislation in the following issues:

• The obligatory use of digital sign as an official communication instrument among the public agencies

• The regulation of e-commerce operation and procurement obligations

• The protection of personal information and security in information systems, in general.

6.5 Functional and Non-functional Requirements

The functionality of the eGOIA demonstrator depends on the functional components and services to be chosen. Besides these functional requirements a set of non-functional requirements are identified that characterize requirements on the execution of the system. A set of global requirements is defined below; a refinement of these requirements will be undertaken during the design phases of the concrete system.

6.5.1 Functional Requirements

Functional requirements are system/software requirements that specify a function that a system/software system or system/software component must be capable of performing. These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs.

For the eGOIA demonstrator the following high-level functional requirements are initially relevant:

• Services Requirements

• Services oriented to Life Cycle Events;

• Services need to be offered in a well-structured and well understandable manner meeting the users´ perspectives and needs;

• Cooperation and integration between the administrative processes (back-office integration) – including the optimization of the organizational workflows if required;

• Ubiquitous common generic services (security, billing, payment, etc);

• Transparent access to the different administrative units; single sign-on (authentication and authorization of user);

• Adopt solutions that can be applied in different geographical regions. Services customized for different groups and adaptation to regional needs.

• Services must be device independent.

• The services offered are customized for the individual rather than having a one-size-fits-all approach.

• Legacy and database system


Version V1.0 15.03.2004 - /93 -

Use of existing legacy systems and use of existing legacy data, avoiding data replication must be possible.

• Content management system

• An efficient Content Management System organizes and administers documents for web appearances and other information presentation.

• Personalized content delivery and customization;

• Support of multilingual content.

• Metadata management system Effective and consistent approach to manage metadata is essential to service collaboration and cooperation among disparate administrative units.

• Document management and preservation There should be a mechanism to ensure that all downloadable forms and documents are kept up to date. Also communications, including the informal ones, between the citizens and the administration should be stored since it belongs to a major process that composes a service being offered.

• Security and privacy General issues on authenticity, integrity, confidentiality. In order to enable trust, transparency, traceability, security, privacy and security, mechanisms have to be developed to provide the same quality and trustworthiness of public services through electronic means as through the traditional way.

• Citizen identification There must be ways to provide electronic user identification, certify and authenticate the documents established in their relations with the administration.

• Cooperation between different public administration units Public administration units need to cross-leverage each other's resources, integrate their systems and data collections. Enterprise integration provides the "glue" that holds together the architectural components required for government transformation and must enables front-to-back (transactional) and horizontal (cross-organizational) integration of government in a manner that is seamless to the customer, whether that customer is a citizen, business, supplier, or employee.

• Payment platform By enabling the deployment of web-based applications, the e-Payment process will improve service delivery by allowing more citizens to access government service via the web. This electronic payment-processing platform must communicate with service instances to provide real-time interactions for departmental services and provide access to any citizen or business using various types of communication device.

• Forms server A server that makes forms available at a logically central location, e.g. a central website or the website arrangement supports an easy localization and retrieval of forms.

• Call center Electronic services must be made available and supported to the users also via traditional communication media.

6.5.2 Non-Functional Requirements

Nonfunctional requirements in software system engineering comprise software requirements that describe not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. These requirements are usually constraints on the services or functions


Version V1.0 15.03.2004 - /93 -

offered by the system. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively.

The ‘IEEE-Std 830 - 1993’ lists 13 non-functional requirements:

• Performance requirements

• Interface requirements

• Operational requirements

• Resource requirements

• Verification requirements

• Acceptance requirements

• Documentation requirements

• Security requirements

• Portability requirements

• Quality requirements

• Reliability requirements

• Maintainability requirements

• Safety requirements

For the eGOIA demonstrator the following non-functional requirements are initially relevant:

• Reliability Resistance to single point failures, supporting graceful degradation and self-healing; Continuity is an important key word. A loss of image of the public agency is expected if a service is often interrupted. In the case of e-Government, a simple interruption can cause a large discredit on part of or a great part of the users.

• Portability The demonstrator should be portable across different platforms. The same service should be accessible from various networks, both from the user’s home network, and from various foreign networks.

• Scalability The demonstrator demands high scalability from the perspective of concurrent usage.

• Security The user has to trust the system and the system has to trust the user (multilateral security). Security targets supporting trust relationships are authenticity, privacy, integrity and confidentiality (see section 6.7).

• Performance The efficiency of e-Government procedures is bound and directly related to software performance.

• Traceability The demonstrator should trace who and from where the system is being accessed. This is to control the access of the system and to avoid inappropriate access.

6.6 Hierarchical, multidimensional Set of weighted Criteria for Requirements Engineering


Version V1.0 15.03.2004 - /93 -

Benefits

Requirements Assessment

CriteriaHierarchical / multi-dimensional

The evaluation of the requirements is supported by developing a hierarchical, multidimensional list of requirements, which can be applied to the dependency of benefit, requirements and assessment. Figure 5 visualizes this dependency during the requirement engineering process which was described in chapter 6.1.

Figure 5: Requirements Strategy

The evaluation process considers quantitative as well as qualitative criteria and is divided into structural and functional requirements:

o Structural requirements:

Costs

Project and Organization

Legal Criteria

Strategic Criteria

o Functional requirements

The criteria for the requirements (as well as those for the benefits and the assessment) will be arranged in a hierarchical, multidimensional list of weighted criteria. These criteria lists will be developed in eGOIA to support the requirements engineering and service selection process, as well as the validation of achieved results.

6.7 Security in e-Government

Ensuring security is one major aspect for the successful implementation of e-Government services. Security represents and supports trusted and secure communication between citizens, public agencies and business. Security is an omnipresent component that can be supported – as demanded or required – by suitable processes, methods and data formats. Technical means must be used in such a manner that trust is created among those who communicate with each other, that baseline protection is ensured and that classical protection aims are fulfilled. Nevertheless only if a need for protection is identified it will be necessary to take protective measures. [10]

6.7.1 Protection Aims

Protection aims [10] define the security interests of communication partners in a general form:

• Confidentiality – protection against disclosure to unauthorized parties: no data is made available or disclosed to unauthorized individuals, entities or processes.

• Integrity – protection against manipulation: unauthorized modification or destruction of data is not possible.

• Authenticity – protection against fake identity/origin. Measures are taken to ensure that an entity or resource (such as an individual, process, system, document, information) actually is what it claims to be.


Version V1.0 15.03.2004 - /93 -

• Availability – protection against failure of IT systems: The properties of an entity and/or resource can be accessed and/or used when this is attempted by an authorized entity.

Information encryption (cryptography) is an important tool for securing confidentiality, integrity and authenticity. A high degree of availability is achieved through multiplicity, distribution and error tolerance.

6.7.2 Protection Requirements

The protection requirements must be identified for each and every IT application. It is a function of the potential damage caused by impairment of the IT application in question. The protection demand can be classified into four categories based on possible damage:

• None: No particular protection is required as no impact from loss or damage is expected.

• Basic to medium: The impact of any loss or damage is limited.

• High: The impact of any loss or damage may be considerable.

• Very high: The impact of any loss or damage can attain catastrophic proportions that could threaten the very survival of the agency/company.

Protection aims, protection requirements and applications define the aims of security measures.

6.7.3 Authentication

Where e-Government services are provided via traditional, non-electronic systems, various authentication mechanisms are used. Citizens are required to sign forms or letters or other types of correspondence as proof that they supplied the information contained in those documents. Citizens may be required to supply an identification number or an account/case number, and they may be required to provide evidence that they are who they say they are, such as a passport, driver’s license or a birth certificate. In some cases, citizens may need to attend the relevant government office in person. Most of these methods will not work online. [18]

Where services are provided online, agencies will need to reassess how they authenticate users. Failure to properly authenticate a communication partner may lead to situations such as the illegal transfer of funds, unauthorized ordering of goods or the falsely alteration of data. Authentication is therefore needed to establish confidence in electronic transactions, to be accepted as valid and binding.

In order to warrant the "authenticity" requirement, certain e-Government applications require the identification and authentication of the communication partners. Different mechanisms are available for authentication, such as user ID / password, PIN/TAN or certificates.

In general authentication relies on one or more of the following principles:

• Something you know, i.e. knowledge such as a password or PIN number

• Something you have, i.e. possession such as a smart card or hardware token

• Something you are, i.e. biometrics such as a fingerprint or iris scans.

Nevertheless an authentication mechanism does not establish a certain security level by itself but is part of a more general procedure, which consists of:

• Identification: To access e-Government services the user might need to perform a registration process, i.e. he has to provide some personal data to achieve the right to access a service. Identification and registration can be technical (online) or non-technical (off-line) process.


Version V1.0 15.03.2004 - /93 -

• Authentication: For online service access and execution the identity of the user has to be provided to an agency. This authentication data is used to decide if the user is who he claims to be.

• Verification: The authentication data of the user has to be verified by the public agency in dependence on the mechanism used.

Before suitable mechanisms for protecting communication within a technical procedure in e-Government can be defined, the required level of protection must first of all be established. The needs in terms of the method and strength of protection will differ depending on the particular technical procedure. The protection required would depend on the damage that could be caused. It should furthermore be ensured that the security level of the conventional technical procedure is also achieved in the e-Government procedure and that legal requirements are also complied with (e.g. legislation, regulations, agreements, contracts etc.).

In some technical procedures it is of relevance

• whether the identity of the customer can be determined "ex ante", i.e. before performance of the service

• whether it is sufficient for the identity of the customer to be determined "ex post", i.e. subsequently.

This is particularly important if there is the possibility that performance of the service could lead to irreparable damage (e.g. disclosure of information regarding serious illnesses or previous convictions to third parties).

In order to be able to evaluate authentication mechanisms, it is important to draw up a list of characteristics for assessing the strength of the mechanisms. Here one needs to differentiate between quality characteristics relating to registration (i.e. everything directly connected with the generation and transfer of authentication data), quality characteristics relating to implementation (i.e. everything connected with using the authentication data) and characteristics for verification (i.e. everything that takes place subsequent to the actual communication between agency and customer).

The strength of authentication mechanisms can be assessed primarily on the basis of the following nine characteristics:

• Quality of registration: quality characteristics relating to registration, i.e. everything directly connected with the generation and transfer of authentication data comprising evidence of identity, trustworthiness of the registration authority, transfer of authentication data.

• Quality of implementation: quality characteristics relating to implementation, i.e. everything connected with using the authentication data comprising authentication principle, disintegration of authentication data and master data, storage of authentication data, security of transmission of authentication data.

• Verifiability: characteristics for verification, i.e. everything that takes place subsequent to the actual communication between agency and customer comprising traceability, ability to log the authentication.

An overview on the relation between different authentication properties and their strength is provided in Table 1. This table is an extract of the Module “Authentication in e-Government” of the German e-Government Manual [11], where the complete explanations can be found.


Version V1.0 15.03.2004 - /93 -

Authentication property / Strength

Basic Medium High Very High

Level of identifiability and/or addressability at registration

Plausibility of identity/address is sufficient

Confirmation of identity/address is required from an entity that is independent of the citizen

Confirmation of identity/address is required from a trusted / guaranteed entity

Appearance by the citizen in person is required or personal receipt by the citizen is required

Evidence of identity at registration provided by the citizen

Provides unverified personal details

Presents some personal document

Is known personally (in a reliable manner) / identified personally

Appears in person and presents an official photo ID

Trustworthiness of registration authority

Citizen registries himself or uses registration authority without defined security level

Third party with defined security level

Third party with warranted or legally guaranteed security level

Public agency (with defined security level) itself is the registration authority for its own purposes

Transfer of authentication data from registration agency to citizen

Public e-mail / phone call

By post By post with response

Transfer in person by employee of the agency or registra-tion authority or No data transfer necessary

Authentication principle

Publicly available knowledge (personal details, such as tax or accounting number)

Secret or Possession of a physical object (e.g. password or TAN list)

Secret + Possession (e.g. smartcard and activation with PIN)

Secret / Possession + Biometric characteristic (e.g. activation of smartcard with fingerprint)

Storage of authentication data by the citizen

Authentication data is accessible (possibly with some effort)

Authentication data subject to software controls

Authentication data subject to hardware controls

Authentication data subject to secure biometric controls

Security of authentication data transmission

Authentication data transmitted without protection (open networks)

Authentication data transmitted in closed networks

Authentication data encrypted before transmission

Transmission of authentication data not required

Logging/Auditing of authentication evidence

Only suitable for documentation purposes

Can be used internally as a means of evidence

Can be used as evidence towards third parties, supplementary agreement needed

Can be used as evidence towards any third party without supplementary agreement

Table 1: Authentication


Version V1.0 15.03.2004 - /93 -

7 SERVICE SELECTION PRINCIPLES

The selection of e-Government services is a major task in the eGOIA project. It is essential for the outcome of the project and provides valuable experiences for the ongoing development of the e-Poupatempo system. Within this chapter the basic targets and principles of the service selection strategy are described. The final selection of the services will not be handled in this document but is part of the strategy planning as well as a major working area of the technical subprojects.

7.1 Stages of Online Availability

In order to classify the level of online availability of the basic public services, the European Commission defines a four-stage framework for e-Government services:

• Stage 1 - Information

• Stage 2 - One-way Interaction

• Stage 3 - Two-way Interaction

• Stage 4 - Full electronic case handling

These stages have been refined in the EU IST KeLAN Project (Key Elements for electronic Local authorities’ Network) [19] that classifies stages 1 and 2 into e-Government enabling generation of systems.

• Stage 0: Not Online. No web presence of local authority through a proprietary website.

• Stage 1: Information. Basic information is provided online on public services and relevant themes for interested parties / stakeholders, such as citizens, enterprises and visitors.

• Stage 2: One-way Interaction. One-way electronic exchange of information (communication) enabled by stand-alone system not linked to the back-office. The website enables downloading of information and forms to apply for services, which can be submitted off-line (by ordinary mail or fax).

The real transforming generations of e-Government systems are more challenging and require redesign of the process of service delivery of local authority:

• Stage 3: Two-way Interaction.

Two-way electronic exchange of information (communication) enabled by means of a website which is linked to the back-office. The website and organization of the back-office enable electronic processing of forms to apply for services. Examples include: electronic communication (sending e-mail and receiving electronic reply, participating in an online chat session / discussion forum); online submitting of application forms for services and online access to personal data.

• Stage 4: Transaction.

Online service delivery enabled by means of a (secured) website which is linked to the back-office. The website and organization of the back-office enable electronic case handling (decision and delivery, including payment) supported by authentication technologies. Examples include (online) access to database with the possibility to view and modify personal data and to monitor (track and trace) service delivery.

• Stage 5: Service Integration.

Online service delivery enabled by means of an integration platform linked to various back-offices / service modules. The website of the local authority enables online access and application of services of other organizations, including electronic case handling (decision and delivery,


Version V1.0 15.03.2004 - /93 -

including payment) supported by authentication technologies. Examples include: (online) access to database of various other organizations, with the possibility to view and modify personal data and to monitor (track and trace) service delivery; access to a forms database shared by different local authorities.

One of the targets of the eGOIA project is to prepare a “Stage 5 Service Integration” system demonstrating value-added services to Latin American citizens.

7.2 Types of Online Services

To group different types of services the following 4 key areas are defined in the EU framework:

• Income-generating: services where payment flows from citizens and businesses to the government (mainly taxes and social contributions)

• Registration: services related to recording data as a result of administrative obligations (births, deaths, marriages)

• Returns: services provided by government to citizens and businesses in return for taxes and contributions (e.g. public libraries)

• Permits & licenses: documents provided by governmental bodies giving permission to build a house, to run a business etc.

7.3 Important Public Services

The EU Member States [7] have agreed a common list of twenty public services (12 for citizens and 8 for enterprises) for which the online sophistication is being benchmarked at national level:

Public Services for Citizens

• Income taxes: declaration, notification of assessment;

• Job search services;

• Social security contributions (Unemployment benefits; Child allowances; Medical costs (reimbursement or direct settlement); Student grants)

• Personal documents (passport and driver's license);

• Car registration (new, used and imported cars);

• Application for building permission;

• Declaration to the police (e.g. in case of theft);

• Public libraries (availability of catalogues, search tools);

• Certificates (birth, marriage): request and delivery;

• Enrolment in higher education / university;

• Announcement of moving (change of address);

• Health related services (e.g. interactive advice on the availability of services in different hospitals, appointments for hospitals.);

Public Services for Businesses

• Social contribution for employees;

• Corporation tax: declaration, notification;


Version V1.0 15.03.2004 - /93 -

• VAT: declaration, notification;

• Registration of a new company;

• Submission of data to statistical offices;

• Customs declarations;

• Environment-related permits (incl. reporting);

• Public procurement;

e-Government services hide the level of complexity lying behind the service offered to the citizen and enterprises. So, depending on the way public administrations are organized, a given e-Government service may imply either a single process or several business processes to be performed in a given sequence between different administrations.

7.4 Criteria for eGOIA Service Selection

Service selection for the eGOIA demonstrator will be based on a combination of pragmatic and ideal criteria. Since it will be hardly possible to assess in depth every service, the eGOIA project applies a combination of criteria that ensures as much as possible the highest pay-off with the minimal risk, while taking into account the characteristics of the technology available to the project.

Criteria for highest pay off:

• National coverage

• Highest demand

• Highly visible results in short- to medium-term.

• High potential for performance improvements (low quality of existing service)

• High potential for cost reduction (expensive existing system)

• High potential for e-inclusion

• High potential of international dissemination

Criteria for minimizing risks

• High degree of required technical expertise and competence, including strong project and financial management skills.

• Existence of strong support by the "user-politician-authority"

• Existence of committed leaders (champions) to drive the work and communication

• None or low degree of misalignment with the legal system

• Low degree of complexity for alignment with legacy systems

• Low potential for resistance from both user-citizens and user-providers

• At this stage, if possible, avoid systems that are mission-critical and involve risks to human lives, or, imply innovations in too many. They are likely to take a long time before showing visible results.

The selection of the eGOIA e-service/s can be first narrowed down to a small number of candidates. Candidates should be chosen based on a “Stage 5: Service Integration” vision (see Section 7.1) heading for an “Important public service for citizen” (see Section 7.3) of course based on the needs in Latin America. These candidates would form the bases for the final selection through the application of two processes:

(1) Deep scrutiny of candidate services in terms of comparative gains with existing systems, technical and legal difficulties, users, management of change, etc. It should also make


Version V1.0 15.03.2004 - /93 -

reference to the potential constraints implied in the technological solutions available to the project.

(2) Reference to best-in-class in Europe and Brazil/Latin America with particular focus on leading-edge concepts, content, features and facilities that the eGOIA system/s may aspire to offer in the short, medium and long term. This would include, for instance, (a) one-stop-shop integrated services with automatic updating of data across services; (b) completely secure service on-demand; (c) “mass customization” by offering users personalization of both interface and content of the one-stop-shop services; (d) high transparency and empowerment through high interactivity for dialogue, collective continuous improvements and e-democracy.

In summary, the practical steps would be as follows:

(1) Select a small number of candidate e-services on the bases of the combination of criteria "high pay-off," "minimum risk," and "constraints of technology available to project."

(2) Conduct deep scrutiny of candidate services in terms of comparative gains with existing systems, technical and legal difficulties, users, management of change, etc.

(3) Apply relevant leading-edge experiences of e-Government services in Europe and Brazil/Latin America today, and see which one/s add complementary richness to the criteria above.

(4) In the light of all inputs, select the e-service/s that will become the base of the eGOIA demonstrator.


Version V1.0 15.03.2004 - /93 -

PART III: General Principles of the eGOIA Demonstrator


Version V1.0 15.03.2004 - /93 -

8 GENERAL PRINCIPLES OF THE EGOIA DEMONSTRATOR

The eGOIA Demonstrator will be an e-Government demonstration system that will support the interaction of citizens with different types of e-Government services through the Internet and Citizen Points of Access (CPAs). For such it will comprise the integration of:

• Back-office procedures: integration of services and access of existing distributed databases for the benefit of the citizen,

• Front-office procedures: supporting appropriated access channels and the functionalities of the services.

These tasks are not simply techniques and they also demand the coordination of different government departments and the cooperation with the public administrative staff.

The distribution of the data used by the eGOIA Demonstrator and the autonomy of the government department responsible for the data result in a complex structure of user-supplier relationships. This situation demands constant negotiation among the several involved entities. Thus, for the development of the eGOIA Demonstrator, the definition of a context becomes necessary, in which all existing agreements between users and suppliers of the system are respected.

The use of modern techniques of Enterprise Modeling is an important aspect in design, development and deployment of a complex software system. The sections below therefore introduce a standardized approach based on Object Management Group (OMG) developments. Afterwards the eGOIA architecture is introduced. A software product supporting exactly this approach is the service integration platform enagoOSP and the tools for service integration in an MDA compliant way (described in detail in Annex C).

8.1 Technical Aspects

In the following sections, some technological tendencies in the IT area are described and an architecture concept introduced, based essentially on the principles of the ODP-RM (Open Distributed Processing Reference Model).

8.1.1 New Technologies

In the last 10 years new technologies appeared, that had deep effects in the software techniques, in the application architectures and in the development methodologies. For the eGOIA Demonstrator some of them are fundamental:

• Object-oriented technologies (OO);

• Principles of incremental development;

• Middleware and new integration technologies (e.g. EAI and Web Services);

• Component Based Software development;

• Metadata Management Systems (e.g. those based in OMG-MOF);

• Model Driven Software Conception and Implementation (UML, MDA, EDOC).

Considering that the IT products innovation cycles are becoming shorter and shorter, the necessity of stability is more and more important. The applications lifetimes are always greater than the lifetimes of hardware infrastructures, of operating systems and of programming languages. For an economical viable solution of the problems caused by these different life times, the demand in the direction of a stable solution of the system increases that implicates in certain requirements of neutrality of the integration platform in relation to the hardware, operating systems, programming languages and


Version V1.0 15.03.2004 - /93 -

databases.

These demands are covered by the Consortium Object Management Group (OMG), to which most of great suppliers adhered during the nineties. Among other patterns, this consortium produced a middleware object oriented specification called CORBA, also guaranteed in the technical solution presented in the proposal of this work. But more than that, OMG made big steps in the last years in the direction of MDA (Model Driven Architectures) which allow more and more the development of software Models independently of the infrastructure used, and the late and dynamic generation of Run-Time systems, which take then in consideration the aspects of Operational Systems, Communication and Middleware used.

8.1.2 RM-ODP Viewpoints

To describe complex distributed e-Government-applications, the Reference Model for Open, Distributed Data Processing (RM-ODP) can be applied. The view of the e-Government system and services is divided into different aspects (viewpoints) and so the complexity of the overall architecture is reduced, thus the advanced technology becomes more understandable and thus more controllable. The basis of RM-ODP is the object-oriented paradigm that promotes clear structures, reusability and maintenance of the created models, components and systems.

The RM ODP model defines five viewpoints on a system, as presented in Table 2:

RM-ODP Viewpoint Areas of concern

Enterprise viewpoint Application area; Purpose and scope; Policies; Responsibilities; Procedures and rules

Information viewpoint Information processing semantics; Information of the system; Data models

Computational viewpoint Functional decomposition; Interfaces; Operations; Binding rules

Engineering viewpoint Distribution of the individual elements of the system on physical resources including their connections

Technology viewpoint Choice and suitability of technology to support system distribution/system realization

Table 2: ODP Viewpoints

The Enterprise Viewpoint for e-Government applications contains two fundamental elements: the organizational structure of e-Government in general and the organizational models of application. Here the total environment of the system and its purpose are described. In addition it defines the requirements for the system, the basic conditions to be fulfilled, and frameworks, constraints and guidelines from view of the organization or the enterprise. It describes also the e-Government procedures, their rules and the stakeholders including their roles participating in these procedures.

The Information Viewpoint specifies the structure and semantics of the information of the system. Further points are the definition of sources (sender) and sinks (receiver) of information as well as the processing and transformation of information by the system. Further integrity rules and invariants are to be described.

In the Computational View a system is divided into functional components, which are suitable for distribution. The result is objects, which possess interfaces, at which they offer and/or use services.

The Engineering Viewpoint describes the necessary system support, in order to permit the distribution of the objects from the Computational Viewpoint. This includes the processing units for objects, like for example the computer and communication infrastructure, as well as all kinds of software platforms for distributed systems.


Version V1.0 15.03.2004 - /93 -

The Technology Viewpoint comprises the concrete technologies to realize the system.

8.1.3 Modeling

Modeling is the design of software applications before coding [20]. Modeling is an essential part of large software projects, and helpful to medium and even small projects as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper. Using a model, those responsible for a software development project's success can assure themselves that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make.

The OMG's Unified Modeling Language™ (UML®) helps to specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements.

With its rich palette and middleware independence, UML forms the foundation of OMG's Model Driven Architecture (MDA). In fact, a UML model can be either platform-independent or platform-specific and the MDA development process uses both of these forms: Every MDA standard or application is based, normatively, on a Platform-Independent Model (PIM), which represents its business functionality and behavior very precisely but does not include technical aspects. From the PIM, MDA-enabled development tools follow OMG standardized mappings to produce one or more Platform-Specific Models (PSM), also in UML, one for each target platform that the developer chooses.

8.1.3.1 MDA

In early 2001, the OMG described the general principles for MDA (Model Driven Architecture).

"The MDA defines an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform. To this end, the MDA defines an architecture for models that provides a set of guidelines for structuring specifications expressed as models. The MDA approach and the standards that support it allow the same model specifying system functionality to be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms, and allows different applications to be integrated by explicitly relating their models, enabling integration and interoperability and supporting system evolution as platform technologies come and go."

Thus, MDA is a software systems development approach based on modeling different aspects and levels of abstraction of a system, separating business from platform concerns, and exploiting relationships between these models.

In the end, MDA is an OMG attempt to raise the level of abstraction of software systems development and focus on describing the systems as models (rather than focusing on code) from which code is automatically derived. Additionally, common problems of integration and interoperability, which are currently solved at platform (middleware) level, will be solved at models level, which reduces complexity.

8.1.3.2 MDA System Models

As already described, each of the ODP viewpoints is related to specific concerns within the software design and development phase as summarized in Table 3.


Version V1.0 15.03.2004 - /93 -

Business Concerns

Computation Concerns

Platform Style Concerns

Platform Concerns

Enterprise X

Information X

Computational X X

Engineering X X X

Technology X X X X

Table 3: Concerns Addressed by the ODP Viewpoints

To model a system MDA defines three kinds of models:

• Computation-Independent Model (CIM)

• Platform-Independent Model (PIM)

• Platform-Specific Model (PSM)

Engineering Viewpoint models are specific to a platform-style, but not specific to any particular platform. Technology Viewpoint models are specific to a platform. Computation Viewpoint models are not specific to any platform style. Enterprise and Information Viewpoint models are computation-independent.

The correlation of the various ODP Viewpoint models to the MDA models is shown in Table 4.

RM-ODP MDA Audience Content

Enterprise Viewpoint CIM Business Owners, Planners,

Managers, Users Business model, System requirements

Information Viewpoint CIM System Analysts Information model,

Information processing model

Computational Viewpoint PIM Software Architects Object model,

Object interaction model

Engineering Viewpoint PIM Systems Architects,

System Administrators Distribution model,

Technology Viewpoint PSM Programmers,

Component Vendors Program code, APIs

Table 4: Correlation of ODP Viewpoint Models with OMG Models

Figure 5 shows the role of the various MDA languages in the various ODP viewpoints [45].


Version V1.0 15.03.2004 - /93 -

Figure 6: EDOC Mapping of Languages for ODP Viewpoints

8.2 Concepts of the eGOIA Demonstrator Architecture

The conception of the eGOIA Demonstrator has to take into account that it has to be possible to reach applications in an open and distributed environment (Internet), configured in flexible way, considering the evolution of the involved government departments. Thus the design and implementation will occur necessarily in several stages.

The eGOIA Demonstrator has to guarantee that external users (citizens) or internal users (employees) have access to services (and its data or databases) through local methods or by Internet access.

A bad-practice solution would be to support only direct access to each separate database. This is impracticable.

The object-oriented technology offers, in compensation, the possibility to access services and existent systems ('legacy wrapping') and their databases. This is supported technologically by a distributed platform with advanced functionalities of communication.

The eGOIA architecture will be a multi-tier architecture. Following these architectural object-oriented principles, the applications will be freed of the existing infrastructure and of available basic services, as for example, the one of communication and of access to databases.

The initial point of the development of the eGOIA Demonstrator should be the analysis of the service and how it is used (use cases). In that analysis, also the databases involved in the services will be identified and the government's departments that manage them. Simultaneously, we need to capture the requirements and develop an operational scenario. That analysis will allow identifying most of the domains and roles that participate in the eGOIA Demonstrator.

The project development model to the specification of eGOIA Demonstrator is illustrated by looking at the nature of the viewpoint specifications, considering the context of São Paulo State Government and the context of other partners of the project.

8.2.1 Enterprise Viewpoint

The focus of the Enterprise Viewpoint is to describe the proposal, scope, general constraints and


Version V1.0 15.03.2004 - /93 -

policies that will govern the eGOIA Demonstrator. So, the main objective of correspondent activities is the extraction of requirements and organizational structure of e-Government, concentrated in the performed actions that change the businesses policies and constraints. That description can be distributed in the following topics:

1. Organizational structure of e-Government and organizational model of an application/service;

2. Description of the environment of the demonstrator;

3. Administrational procedures, rules and actors;

4. Process models, process optimization, usage scenarios;

5. Qualifying/teaching of personnel.

A key structuring concept in ODP Enterprise Viewpoint is that of a community. A community is a configuration of enterprise objects modeling a collection of entities (human beings, information systems, resources and etc) interacting to achieve the objective of the community concerned. Three community types are defined by ODP: domains, federations and ownership communities. In our case domains are considered to introduce the notion of autonomy, authority and control.

Figure 6 illustrates some of those possible communities, relative to the eGOIA Demonstrator and their objectives are described bellow.

• Users Domain: joins all the participating parts like the citizens, state servants and enterprises, and contains the elements for user interaction;

• Workspace Domain: is responsible for the logic of the pattern of interaction with the user (e.g. Web Access through Browsers, kiosk, Citizen Points of Access, etc);

• Services Domain: Includes the services themselves, that may be numberless and of very different nature;

• Integration Domain: this domain will be of huge importance in the eGOIA Demonstrator Community because it treats, among others aspects, the Integration of Database and Application legacies, and integration of services from the Services Domains and connectors infrastructure.


Version V1.0 15.03.2004 - /93 -

Figure 7: Overview of Domains in the eGOIA Demonstrator Community

8.2.2 Information Viewpoint

The information models reveal the types of information managed and processed by the system. These modeling tasks can be distributed in the following topics:

1. Structure and semantic of information,

2. Sources and sinks of information,

3. Processing and transformation of information on its way through the system

4. Generic data models (reusable, simple, mapping to existent data)

5. Information and schema repositories

It is not necessary to stress here the importance that this viewpoint assumes in the context of the project. Not only, the diversity of domains implies a great diversity of Information to be modeled, but also the nature itself of the integration domain brings the huge amount of database Information to be considered by the processing logic of other domains.

8.2.3 Computational Viewpoint

The Computational Viewpoint describes the functionality of the eGOIA system in order to carry out the processing required by the system roles in the enterprise specification. It does this in terms of functional decomposition of the system into computational objects (components) that interact through interfaces, and thereby enables distribution. It defines also the collaboration structures among a set of


Version V1.0 15.03.2004 - /93 -

computational objects. The Computational Viewpoint is closely related to the enterprise viewpoint in the sense that the computational components result from the functional mapping of enterprise concepts like enterprise objects and their roles.

The focus of the Computational Viewpoint is thus to describe the functional decomposition of the application, regarding to the logic partitioning of the distributed system in several computational objects that interact amongst them. Within each domain the functions will be distributed into components interacting via defined interfaces (local or remote interactions) or through the exchange of messages. Interactions have to be secured (authentication, authorization, integrity of data and processes, confidentiality).

Aspects such as reusability of software components and interoperability of the applications and components are very relevant in the Computational Viewpoint. Basic components must be identified and be able to be integrated in the implementation of different applications. For the interoperability aspect, it is essential to adopt a standardized approach.

8.2.4 Engineering viewpoint

The engineering specifications are derived from the computational specification by applying technology mappings. The technology mapping incorporates standard interfaces and naming protocols to define consistent interface types and specifications. The focus is to describe the mechanisms and functions needed to deal with distributed interactions among the systems objects, exposing their distribution requirements and transparency.

In this phase of the eGOIA development, decisions have to be considered regarding the underlying type of platform or technologies. The models developed in the Enterprise, Information and Computational Viewpoints, which will be platform independent, must be mapped to platform specific models.

One of the key aspects of the engineering specification is the strategy for distributed computing, regarding issues such as:

• Which objects are network accessible and which are not: objects that are not network accessible must be co-located with objects with which they have relationships or from which they receive messages;

• The scope of transactions and the use of asynchronous messaging;

• Which elements are persistent and how they are mapped to a persistent data store.

EGOIA software architecture is illustrated in Figure 7, which depicts the software logical architecture and an envisioned physical distribution using five tiers.

The logical architecture is comprised of three major blocks:

• The User Logic deals with the functionality required by the user and the devices used;

• The Business Logic is comprised of the processing services responsible for common services (both domain specific and general) that can be used by multiple users. Legacy systems and integration components belong to this block;

• The Persistence Logic is responsible for physical data storage and data management.

Regarding component distribution, eGOIA project aims to achieve a multi-tier structure, described as follows.


Version V1.0 15.03.2004 - /93 -

• The Client Tier represents different access channels, required by different users, terminals, transmission paths, as well as different application purposes, in order to interact with dedicated applications. The different access channels comprise e.g. Web access over Web Browser or special Browser plug-in, portable radio telephones and personnel digitally Assistants (PDAs), and external systems.

• The Presentation Tier describes the information preparation for the client and the interaction of the user with dedicated applications. The presentation component covers all standards for communication with the regarded end-systems of the Client Tier.

• The Business Tier encloses the e-Government components and services and can be regarded as the core of e-Government-specific applications. In this tier the specific business logic of the diverse e-Government applications is combined and integrated. In this tier the highest integration need is expected for e-Government solutions. The Business Tier processes the data from the persistence tier.

• The Persistence Tier comprises the back-end and guarantees the data storage. Data storage is usually solved by means of databases. The back-end stands as comprehensive term for functionalities of the operating system, specific databases, and in addition, for existing legacy or ERP systems and services.

Figure 8: Multi-tier structure of eGOIA Demonstrator

8.2.5 Technology viewpoint

The technology viewpoint is concerned with the choice and deployment of software and hardware products for implementing the demonstrator and with the associated mappings from platform specific models (PSM) the corresponding technologies (e.g. J2EE with EJB, Flow Composition Model (FCM), CORBA 3 with CCM and MS DNA/.Net with DCOM).


Version V1.0 15.03.2004 - /93 -

In the choice of technologies to implement the system, different aspects are considered, such as, identification, distribution and installation of specific software and hardware technologies to support the system. This description can be distributed in the following topics:

1. Technology to implement/realize the system,

2. Standards to be used to realize the system

3. Enabling technologies to eGOIA project (components, Web services, semantic Web, Ontologies, etc)

The eGOIA project has chosen a service integration platform that supports the needs for modern e-Government service integration scenarios. This platform is already used for e-Government in Berlin, Germany.

The enago Open Service Platform (enagoOSP) provides a uniform service access, execution and management environment, particularly across different administrative and technological domains. It is based on state of the art CORBA and Java 2 technologies that enables component based e-service and service portal implementation. enagoOSP has been designed to support efficiently and economically the different roles involved in e-Government, namely end users/citizen, government offices, infrastructure providers and third party providers by the provision of a unique service integration platform.

The main focus of enagoOSP is to enable the integration, composition and management of existing and emerging application services based on different programming languages, different access technologies and different service technologies, and to provide a controlled (secure) and uniform access to these services by means of one-stop shopping and single sign on capabilities including customization by means of profiles to the customers and end users.

A more detailed overview can be found in Annex C.


Version V1.0 15.03.2004 - /93 -

PART IV: Conclusions and Recommendations


Version V1.0 15.03.2004 - /93 -

9 CONCLUSIONS, RECOMMENDATIONS AND FUTURE WORK

This chapter concludes the work presented in the above chapters and provides an outlook towards the work to be done in the future.

9.1 Conclusions

Chapters 3,4,5,6 and 7 identify several aspects that allow a good diagnosis at the start of the eGOIA project.

9.1.1 Existing Knowledge

The deliverable considers the situation of existent e-GOV programs in three partners: Brazil, Peru and Portugal.

1. To articulate and focus the different initiatives and projects providing universal access to services delivered by the federal government in Brazil, an Electronic Government (e-GOV) Program was launched, under the leadership of the Presidency of the Republic. This program has several similarities with the objectives stated in eGOIA.

2. The creation of Citizen’s Services Centers (e.g. Poupatempo) in almost all the Brazilian states (nowadays 23 out of 27 existing States), which gather several agencies carrying out services from any area of the government in a unique space, has created a great advance on the answering of the demands of the civil society. However, the facility introduced by these Centers contributed to the performance of hundreds of services in a single space do not resolve the problems of the citizens presented by the specification of public services.

3. The great challenge presented in Brazil, and in particular in S.Paulo, is the possibility of the construction of virtual citizen’s services centers, where it will be possible, by the integration of the legacy systems, the access to public services and information without the obligatory repeated certifications and where it will be possible to establish a new form of relationship between State and Citizen unlike the current fragmented one.

4. Peruvian e-Government is just barely in its infancy. Growth is predicted for the next several years, as in all of Latin America, but Peru still has major steps to take in order to truly make it attractive for electronic government opportunities.

5. Portugal’s vision for e-Government was set out in The Green Book for an Information Society in Portugal, known as the Open State. The related program of action, Open State: Modernizing Public Administration was the basis for the foundation of Internet initiative announced by the Portuguese Government in 2000.

6. The consolidation of the European Union approach to Information Society (IS), materialized in the approval of the eEurope Action Plans within the framework of the Lisbon Strategy, has induced significant changes in the Portuguese IS policy. In November 2002 a new Portuguese IS strategy was approved. This new strategy closely follows the guidelines of the eEurope 2005 Action Plan, as it aims to create the conditions for the development of applications and contents, and of safe online public and private services through widely available broadband infrastructures.

9.1.2 Good Practices of eGOIA Partners

The eGOIA partners bring together a rich experience in Government Services:


Version V1.0 15.03.2004 - /93 -

1. The Brazilian Government has placed a high priority on the adoption of advanced information communication technologies for its administrative processes and delivery of services to citizens. This has already produced remarkable achievements. For example, the Federal Government already offers a broad range of services through the Internet; most of them are available through the Redegoverno portal (http://www.redegoverno.gov.br), which includes more than 2,000 services and 20 thousand different categories of information.

2. The demand for the public services offered electronically has increased and in order to supply it, numerous electronic citizen service centers throughout Brazil have been created according to the e-Poupatempo model of the São Paulo State. These centers aim the simplification of procedures to obtain the services as well as the direct access of the citizens. They will serve as major reference for the specification and implementation of the eGOIA Demonstrator.

3. In Peru there are also several good practices in e-GOV under the way of installation, The Registry Information System (SIR), the System of Automatic Acquisitions and Contracts for the Peruvian Government (SEACE) and a Automated Voting System, are good examples.

4. FOKUS, the main technological partner of eGOIA, brings an experience acquired with the participation in several projects in the Berlin City Administration, like VeZuDa, BLIS and an information system – Start-Infosystem – realized in the years 1996-2002. These systems will dictate directly the architecture of the eGOIA Demonstrator. A Discourse Support System named Zeno is also to be considered. One of the many successful applications of the Zeno was the use as a part of the foundation of the DEMOS system (http://demos-project.org). DEMOS stands for Delphi Mediation Online System and was an e-democracy research and development project founded by the European Commission (IST-1999-20530).

5. Portugal has a solid base of services developed around the intentions of citizens, especially in the regulation sector. One example of that service is the registry agency Direcção Geral dos Registos e do Notariado. Portugal’s public services portal (INFOCID - Portal da Administração Pública Portuguesa) offers the several services on-line. There are a number of other encouraging projects in the pipeline.

9.1.3 Technical Frameworks and Standards

Architectures for IT in public administration must consider and take into account the specific situation of adopting systems that already exist and being operated – evolutionary vs. revolutionary IT concepts and IT strategy. The specific concern of Brazil was outlined and the basic approaches in Europe towards a global e-Government framework and standardized approach were described:

1. Brazil has lacked effective long-term policies, regarding e-Government architecture, standards and reference models. The Public Key Infrastructure and the Brazilian Payment System are initiatives towards an e-Government framework and standardized approach.

2. EU leaders at Seville launched the eEurope 2005 Action Plan in June 2002. Public services are expected to become more user-friendly and personalized and adapted to the needs of individuals. IDA (Interchange of Data between Administrations) is a European Commission driven strategic initiative using advances in information and communications technology to support rapid electronic exchange of information. It will address information content and recommend technical policies and specifications for joining up public administration information systems across the EU. It will be based on open standards and encourage the use of open source software.” The European Interoperability Framework (EIF) is to support the pan-European delivery of electronic government services.

3. BundOnline2005 is the e-Government program of the German government announced on September 2000. The free objective of the program is to have 2005 all Internet-capable services of the federal administration on-line available. The German “Standards and Architectures for e-Government Applications (SAGA)” provides the recommendations for the implementation of interoperable e-Government systems and services based on international standards. The document presents standards, processes, methods and products of state-of-


Version V1.0 15.03.2004 - /93 -

the-art IT development for e-Government applications in a concise form. OSCI (Online Service Computer Interface) is a two-layered protocol, developed by Bremen Online Services and now a mandatory standard in German SAGA and also integrated in the IDA Specification of the European Commission [6].

4. The UK GovTalk consultation processes set the technical standards that support information to flow seamlessly across the public sector to provide citizens and business with better access to government services. The e-Government Interoperability Framework (e-GIF) addresses mandatory specifications and policies to adopt the Internet and World Wide Web specifications for all government systems in the UK.

5. Within e-GOV activities, the USA OMB’s Federal Enterprise Architecture Program Management Office (FEAPMO) has continuing stewardship responsibilities for the E-GOV Initiatives. This is part of the FEAPMO’s larger role in defining a Federal Enterprise Architecture (FEA) - a function-driven framework for describing the business operations of the Federal Government independent of the Agencies that perform them. The FEA provides a consistent, industry-aligned architecture for definition of and communication about the components commonly needed to deliver E-GOV solutions.

9.1.4 General Demonstrator Requirements and Constraints

Several general requirements and constraints have been identified.

1. Citizens Needs: The eGOIA Demonstrator must provide to the citizens (Brazil and Peru) efficient public services of good quality. The use of modern Internet technology is regarded as a technology to support citizens’ daily business with the public administration such that it becomes easier and quicker. As a result several requirements must be fulfilled as for example, minimize the physical presence of the citizen, simple access by a user-friendly Web portal, support to a variety of user end-systems and access methods, non-stop service offer, proactive government and promoting participation in democratic processes.

2. Civil Servant Needs: Besides the citizens also the civil servants / administrative employees are directly influenced by the new developments towards electronic access and execution of public services. There are diverse requirements from their point of view, as the need to train them to handle the new paradigm: from bureaucracy-centered to citizen-centered government, to enable employees to access necessary information in a simple and fast way. Knowledge management leads to better cooperation and continuing education.

3. Organizational Requirements: A set of requirements is imposed by the organization (public administration). The development of the eGOIA demonstrator must consider that a new paradigm is being introduced (from bureaucracy-centered to citizen-centered government) with the consequence of the optimization of internal and external business processes. Although a single point of access to e-services is to be constructed, the information is offered by different public administrative units and thus constraints and policies of the involved administrative units have to be clearly identified. Employee acceptance and financial constraints have to be considered. But the access to the databases owned by the different units, mostly legacy databases, poses the most stringent constraints. Ownership of databases and data imposes constraints on the accessibility and transmission of data, on the data integration and maintenance and degree of privacy imposed.

4. Domain Requirements (e-Government): The domain tackled by eGOIA owns special characteristics. Regulations and legal requirements may be boundaries for the eGOIA project that have to be examined and respected. For example the use of electronic signatures and the laws protecting security and privacy are to be considered in each country (e.g. Brazil and Peru).

5. Functional Requirements: The functionality of the eGOIA demonstrator depends on the functional components and services to be chosen. Although the specific detailed requirements are due as input before the Demonstrator construction, some well-known and mandatory


Version V1.0 15.03.2004 - /93 -

requirements are proposed in the document and should be considered in the respective subprojects of eGOIA.

6. Non-functional requirements in software system engineering comprise software requirements that describe not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. The ‘IEEE-Std 830 - 1993’ list of non-functional requirements is recommended. Reliability, portability, scalability, security, performance and traceability are some examples relevant to eGOIA.

7. Security in e-Government: Ensuring security is one major aspect for the successful implementation of e-Government services. Security represents and supports trusted and secure communication between citizens, public agencies and business. Security is an omnipresent component that can be supported – as demanded or required – by suitable processes, methods and data formats. Technical means must be used in such a manner that trust is created among those who communicate with each other, that baseline protection is ensured and that classical protection aims are fulfilled, i.e. confidentiality, integrity (of data), authenticity and availability. Cryptography (encryption and digital signatures) is the technical method for securing confidentiality, integrity and authenticity. A high degree of availability is achieved through multiplicity, distribution and error tolerance.

8. Authentication: Where e-Government services are provided via traditional, non-electronic systems, various authentication mechanisms are used. Citizens are required to sign forms or letters or other types of correspondence as proof that they supplied the information contained in those documents. Citizens may be required to supply an identification number or an account/case number, and they may be required to provide evidence that they are who they say they are, such as a passport, driver’s license or a birth certificate. In some cases, citizens may need to attend the relevant government office in person. Most of these methods will not work online. Where services are provided online, agencies will need to reassess how they authenticate users. Authentication is needed to establish confidence in electronic transactions, to be accepted as valid and binding.

9.1.5 Selection Principles of eServices

The selection of e-Government services is a major task in the eGOIA project. It is essential for the outcome of the project and provides valuable experiences for the ongoing development of the e-Poupatempo system.

1. Stages of Online Availability: Services can be classified into different levels of on-line availability, as it is explained in EU IST KeLAN Project. One of the targets of the eGOIA project is to prepare a “Stage Service Integration” system demonstrating value-added services to Latin American citizens where online service delivery is enabled by means of an integration platform linked to various back-offices / service modules. The website of the local authority enables online access and application of services of other organizations, including electronic case handling (decision and delivery, including payment) supported by authentication technologies.

2. Types of Online Services: One should try in eGOIA to group different kinds of services accordingly to different aspects like income generating (e.g. taxes and social contributions), registration (births, deaths, marriages), returns (e.g. public libraries) and permits and licenses. Different Poupatempo services fall in these categories.

3. Important Public Services: The EU Member States have agreed a common list of twenty public services for which the online sophistication is being benchmarked at national level. Some of these services are being considered in eGOIA as for example, personal documents (identity cards and driver's license), car registration, etc. Public services for businesses will not be considered, at least not in the first stage of eGOIA.

4. Criteria for eGOIA Service Selection: Service selection for the eGOIA demonstrator will be based on a combination of pragmatic and ideal criteria. Since it will be hardly possible to


Version V1.0 15.03.2004 - /93 -

assess in depth every service, the eGOIA project applies a combination of criteria that ensures as much as possible the highest pay-off with the minimal risk, while taking into account the characteristics of the technology available to the project. The selection of the eGOIA e-services can be first narrowed down to a small number of candidates. Candidates should be chosen based on a “Stage: Service Integration” vision, heading for an “Important public service for citizen” of course based on the needs in Latin America. These candidates would form the bases for the final selection.

9.2 General Principles of the eGOIA Demonstrator: Recommendations

The eGOIA Demonstrator will be an e-Government demonstration system that will support the interaction of citizens with different types of e-Government services through the Internet and Citizen Points of Access (CPAs). For such it will comprise the integration of back-office and front-office procedures. These tasks are not simply techniques and they demand the coordination of different government departments and the cooperation with the public administrative staff.

The experience, best practices and products of European eGOIA partners (mainly of FOKUS) allow the use of modern technologies in the construction of eGOIA, in order to maximize the demonstration effect. The following technologies are recommended:

1. Recent technologies are to be used, as object-oriented technologies (OO), principles of incremental development; middleware and new integration technologies (e.g. EAI and Web Services), component-based software development; Metadata Management Systems (e.g. those based in OMG-MOF) and Model-Driven Software Conception and Implementation (UML, MDA, EDOC).

2. RM-ODP Viewpoints: To describe complex distributed e-Government-applications, the Reference Model for Open, Distributed Data Processing (RM-ODP) is recommended. The view of the e-Government system and services is divided into different aspects (viewpoints) and so the complexity of the overall architecture is reduced. The basis of RM-ODP is the object-oriented paradigm that promotes clear structures, reusability and maintenance of the created models, components and systems.

3. Modeling is the design of software applications before coding. Modeling is an essential part of large software projects, and helpful to medium and even small projects as well. Using a model, those responsible for a software development project's success can assure themselves that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make. The OMG's Unified Modeling Language™ (UML®) helps to specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements. With its rich palette and middleware independence, UML forms the foundation of OMG's Model Driven Architecture (MDA). All these concepts should be used intensively in the construction of the eGOIA Demonstrator.

4. The conception of the eGOIA Demonstrator has to take into account that it has to be possible to reach applications in an open and distributed environment (Internet). The eGOIA Demonstrator has to guarantee that external users (citizens) or internal users (employees) have access to services (and its data or databases) through local methods or by Internet access.

5. The eGOIA architecture will be a multi-tier architecture. Following these architectural object-oriented principles, the applications will be freed of the existing infrastructure and of available basic services, as for example, the one of communication and of access to databases.

6. The initial point of the development of the eGOIA Demonstrator should be the analysis of the service and how it is used (use cases). In that analysis, also the databases involved in the services will be identified and the government's departments that manage them. Simultaneously, we need to capture the requirements and develop an operational scenario. That analysis will allow identifying most of the domains and roles that participate in the eGOIA Demonstrator.


Version V1.0 15.03.2004 - /93 -

7. The implementation of the Demonstrator shall follow the ODP principles and use of MDA tools. In principle, several of the projects represented by the partners will be considered. The whole work will be mainly of the kind of reverse engineering, reusing models, tools and components already disposable and adapting some of them, if necessary. Only if strictly necessary new elements will be introduced

8. The eGOIA project has chosen a service integration platform that supports the needs for modern e-Government service integration scenarios. This platform is already used for e-Government in Berlin, Germany. The ENAGO Open Service Platform (enagoOSP) provides a uniform service access, execution and management environment, particularly across different administrative and technological domains enabling component based e-service and service portal implementation. enagoOSP has been designed to support efficiently and economically the different roles involved in e-Government, namely end users/citizen, government offices, infrastructure providers and third party providers by the provision of a unique service integration platform. enagoOSP is based on state of the art middleware technologies, such as the Common Object Request Broker Architecture (CORBA), Java 2 Enterprise Edition (J2EE).

9. The main focus of enagoOSP is to enable the integration, composition and management of existing and emerging application services based on different programming languages, different access technologies and different service technologies. This diversity will be supported by the recently introduced MDA methodology. Based on OMG’s MDA compliant approach for the rapid definition and development of software systems a modeling infrastructure is available, that supports the software development for enagoOSP based on UML, EDOC, and MOF. This modeling infrastructure contains modeling and development tools and their interconnection. Each of these tools or modeling techniques supports a different phase or activity in the development process for the eGOIA Demonstrator.

9.3 Outlook to the Work of the other eGOIA Subprojects

Based on this deliverable eGOIA continues work in subproject 2 and in the following subprojects as described below.

9.3.1 Outlook to D.2.2

A detailed definition of strategies to build the demonstrator will depend on the identification and selection of the eGOIA e-service/s. Of course, some criteria with general validity for all cases can be pointed out, especially if we see the realization of the demonstrator as a process of evolutionary alignment involving the technical, social, legal, economic, cultural aspects of the overall process. This means that eGOIA must pursue alignment strategies that take into account, for instance:

• Alignment to existing legal frameworks, or, conversely, trying to align legal frameworks to the implementation demands of the new technology/service. The case of change in Germany's legislation to allow for digital signatures is a good example of the second case.

• Alignment among all the necessary technical constituents of the new system, for instance, in terms of appropriate costs, performance, standards and intellectual property.

• Alignment to existing legacy systems, or, gradual evolution towards displacement of mis-aligned legacy systems

• Alignment with personnel's expertise and competence, or, alignment of personnel's expertise and competence to the requirements of the system through for instance training.

• Alignment with user-citizens' requirements and expectations, or, re-alignment of user-citizens' requirements and expectations to new capabilities of the system, hopefully, for the better.

The Deliverable D.2.2 (eGOIA Strategy Report) will handle and point out strategies and methodologies that clarify and support the above-mentioned alignment procedures and will provide input for the consecutive subprojects of eGOIA. The content comprises the following topics:


Version V1.0 15.03.2004 - /93 -

• Definition of a hierarchical, multidimensional set of weighted criteria for requirements engineering

• Service selection (criteria, selection, description)

• Strategies to build the demonstrator, i.e. techniques on how to proceed in implementing the project

• Operational concepts (operation; change management; administrative roles, rights and responsibilities; quality assurance; recovery management and support, security, organizational agreements, training of personnel, documentation)

• Methodology on validation of results

• Strategies and methods for the multiplication of results within Brazil, to Peru, to Europe (concepts, portability, multi-language)

• Dissemination methods (publicity, persuasion)

9.3.2 Outlook to SP3

SP3 has as objectives to select the services to be developed in the demonstrator considering the defined objectives and strategies from SP2, to identify the requirements to feed SP4 and SP5, as well as to continuously evaluate the implementation results.

Thus, activities will be carried out aiming at:

• The evolvement of the laboratory;

• The selection of the services to be developed in the demonstrator, considering the defined objectives and strategies from SP2;

• The definition of users groups (D.3.1) and application of questionnaires to identify their needs (D.3.2); existent methodologies and present surveys results will be taken as reference to the analysis of the expectations and needs of people that use public service through Internet, and to adjust and apply them to the context of eGOIA;

• The establishment of functional and technical requirements for the demonstrator (phases 1 and 2);

• The resulting assessment of its implementation, based on user group satisfaction and the verification of the requirements accomplishment;

• The feeding the results into the other subprojects.


The main objective of subproject 4 is to specify and construct a demonstrator to support a set of public services, supporting back-office processes and data integration, that allow the public sector to provide citizens, business partners and administrative staff with information, based on life-events and business situations.

To achieve its objective, SP4 must take into account relevant e-Government experiences presented by eGOIA partners. Subproject 4 should, especially, consider:

1. The use of EnagoOSP platform and VeZuDa best practices in the construction of the demonstrator;

2. The use of modern techniques of software modeling as the one proposed by MDA. Platform-independent models, representing business functionality, entities and behavior, must be precisely defined with no technical features included. Standardized mappings tools must be used to produce models specific to the platforms adopted by eGOIA project.


Version V1.0 15.03.2004 - /93 -

Subproject 4 will have many requirements and constraints as input: the general ones proposed in this deliverable and those that will be posed by the selected services. To deal with this situation it is important that:

3. Deliverable 2.2 ⎯ eGOIA Strategy ⎯ presents a strategy for the selection and weighting of the general requirements.

Finally, the success of eGOIA demonstrator depends on the selected services. Subproject 4 must ensure that the selected services:

4. Provide to the demonstrator valuable features of the government domain.


The requirements and specifications come from subproject 3, referring to the citizen, offer important demographic and socio-cultural profiles to the three main objectives of the subproject 5:

- The definition of the equipment (hardware/devices) to demonstrate the services;

- The physical/geographical localization of the access points; and

- The graphical interface (front office), necessary for the usage of the selected services, taking into account the type of devices and the profile of the citizen, as well as the virtual environment, where these services will be.

For in such a way, principles of digital design, usability, accessibility and governmental standards of communication with the citizen will help to compose the interfaces’ functional and technical requirements, and the construction of interface design. The specific development of the interfaces for the demonstrator, foreseen for the D.5.2 (Phase 1) and D.5.3 (Phase 2), intents the creation of the digital environment of access of the citizen to the services, in face of the requirements, devices and localization of the CPAs, its installations and dedicated design for the final user, using the metaphor of life-events, thus constituting the front office.

Also, the composition and distribution of the target population in the state territory, as provided by local statistical data, and their preferences of use and equipments for accomplishment of electronic services, disclosed through field research, will indicate the points of access, medias and devices for the installation of the demonstrator. These aspects are part of the content of the deliverable D.5.2 and they must influence the decisions and alternatives of development of subprojects 4 and 6.

The challenge of this subproject is in creating a layer of approach between the citizen and the computer, in order to guide through the service, considering:

1. The medias and the availability the equipment;

2. The accomplishment of the electronic services by users with and without assistance of attendants (mediators);

3. The cultural relationship of the citizen with the presential attendance;

4. The nature of the services and the easiness of use are determinative for the success of the demonstrator; and

5. The gathering of methods and technologies to be suitable for similar realizations in other states and countries.


Version V1.0 15.03.2004 - /93 -

10 REFERENCES

[1] EU eGovernment R&D website: http://europa.eu.int/information_society/programmes/egov_rd/text_en.htm [2] United Nations and American Society for Public Administration, Benchmarking E-government: A global

perspective, 2001, http://www.unpan.org/e-government/Benchmarking%20E-gov%202001.pdf [3] Nick Lancaster and Alfonso Molina: Towards eCitizenship for All, Issues and Trends for Future Policy and

Strategy in eGovernment, TeleCities contribution to the EU 6th framework programme, http://www.telecities.org/activities/policy.asp

[4] European Commission, eEurope 2005: An information society for all, Action Plan, May 2002, http://www.eurocities.org/eurocities/Documents/eEurope2005ActionPlan.pdf

[5] Value Creation in eGovernment projects, An exploratory analysis conducted for the Danish presidency of the eGovernment workgroup of the Directors General, Report prepared for the November 2002 meeting of the eGovernment workgroup of the Directors General of Public Administrations, and published in early January 2003 by the Danish government's Digital Taskforce, 2002/03 http://www.e.gov.dk/sitemod/upload/Root/English/Value_Creation_in_eGovernment_projects.pdf

[6] IDA, Interchange of Data between Administrations, EC Initiative, http://europa.eu.int/ISPO/ida/ [7] European Interoperability Framework for pan-European eGovernment Services (EIF), IDA working

document, Version 4.2, January 2004, http://europa.eu.int/ISPO/ida/export/files/en/1674.pdf [8] G. Kotonya and I. Sommerville: Requirements Engineering Processes and Techniques, 2000,

http://www.software-engin.com [9] German Government, BundOnline 2005, http://www.bund.de/Service/english-.6118.htm [10] KBSt unit, Federal Ministry of the Interior of Germany: SAGA - Standards and Architectures for e-

Government Applications, Version 2.0, December 2003, http://kbst.bund.de/saga [11] German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik

(BSI)), E-Government Manual, http://www.bsi.de/fachthem/egov/3_en.htm [12] OSCI Leitstelle: OSCI Transport 1.2, Design Principles, Security Objectives and Mechanisms, Bremen,

Germany, May 2002, http://www.osci.de/materialien/requirements.pdf [13] OSCI Leitstelle: OSCI Transport 1.2, Specification, Bremen, Germany, May 2002,

http://www.osci.de/materialien/osci-specification_1_2_english.pdf [14] United Kingdom, UK GovTalk, http://www.govtalk.gov.uk/ [15] United Kingdom, e-GIF, http://www.govtalk.gov.uk/schemasstandards/egif.asp [16] Office of the e-Envoy, Trust & Security in e-Government,

http://www.e-envoy.gov.uk/Responsibilities/Security/fs/en [17] USA, Federal Enterprise Architecture Program Management Office (FEAPMO), http://www.feapmo.gov [18] National Office for the Information Economy, Australia, Online Authentication, 2002,

http://www.noie.gov.au/publications/NOIE/online_authentication/OnlineGuideFinal.pdf [19] EU IST KEeLAN Project, Report on use of the Internet by local governments and best practices, June

2002, http://www.keelan.ie/uploads/documents/egovernment/020618_D4.doc [20] OMG, Introduction to OMG's Unified Modeling Language™ (UML®),

http://www.omg.org/gettingstarted/what_is_uml.htm [21] David Frankel Consulting for INTAP, Applying EDOC and MDA to the RM-ODP Engineering and

Technology Viewpoints, An Architectural Perspective, Version 01-00, 17 October 2003 [22] Proposta de Política de Governo Eletrônico para o Poder Executivo Federal

http://www.governoeletronico.e.gov.br/arquivos/proposta_de_politica_de_governo_eletronico.pdf [23] E-Gov Enterprise Architecture Guidance (Common Reference Model) http://www.cio.gov/documents/E-

Gov_Guidance_July_25_Final_Draft_2_0a.pdf [24] E-Government Strategy – Simplified Delivery of Services to Citizens. February 27, 2002

http://www.cio.gov/documents/EgovStrategy.html [25] Electronic Government Services Key priorities for the Citizens Advice service.

http://www.eastdorset.gov.uk/democracy/docstore/0309/030904121854-cd7c4d45-ccda-4cd6-b6af-fa580df97e03.pdf

[26] Providing Innovative Service Models and Assessment - Good practice in eAdministration service deliver, March 2002. http://www.prisma-eu.net/pages/D3.2%20conclusions%20and%20themes.pdf

[27] Arcieri F., Melideo G., Nardelli E., Talamo M., Experiences and issues in the realization. Proceedings of the 12th Intl. Workshop on Research Issues in Data Engineering: Engineering e-Commerce/ e-Business Systems (RIDE.02), 2002. http://galileo.dm.univaq.it/~nardelli/publications/RIDE-02.pdf


Version V1.0 15.03.2004 - /93 -

[28] Information Technology Division – Strategic Planning Group - SPG - FY2003 Investment Brief Ver2 http://www.state.ma.us/itd/spg/services/itplanning/bondfunded2002/dph101.pdf

[29] Enterprise Architecture and Government Transformation Services http://www.ams.com/publicsector/transformation/

[30] Kolp, Manuel; Giorgini, Paolo; Mylopoulos, John. Organizational Patterns for Early Requirements Analysis. In: Proceedings of the 15th Conference On Advanced Information Systems Engineering (CAiSE*03), Austria, 16 - 20 June, 2003. http://citeseer.nj.nec.com/563410.html

[31] Castro, Jaelson; Alencar, Fernanda; Cysneiros, Gilberto. Closing the GAP between organizational requirements and object oriented modeling, Journal of the Brazilian Computer Society, v.7 n.1, 2000. http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-65002000000200002&lng=pt&nrm=iso

[32] O que é o Poupatempo? - http://www.poupatempo.sp.gov.br [33] Cap Gemini (prepared for European Commission – DG Information Society): Online availability of public

services: How does Europe progress? - Web-based survey on electronic public services (Overall report Oct 2001 - Oct 2003), January 2003, http://www.cgey.be/pdf/CGEY-EuropeOnlinePublicServicesOverallReport.pdf

[34] Accenture: eGovernment Leadership – Realizing the Vision, 2002, http://www.accenture.com/xdoc/en/industries/government/eGov_April2002_3.pdf

[35] Accenture: eGovernment Leadership Rhetoric vs. Reality - Closing the Gap, 2001, http://www.accenture.com/xdoc/en/industries/government/2001FullReport.pdf

[36] Commission of the European Communities: Communication from the Commission to the Council, the European Par lament, the European Economic and Social Committee and the Committee of the regions – The Role of eGovernment for Europe’s Future (Brussels, 26.09.2003 COM (2003) 567 final).

[37] UMIC – Unidade de Missão Inovação e Conhecimento: Sociedade da Informação e Governo Electrónico – Relatório Diagnóstico.

[38] David S. Frankel, Model driven Architecture: Applying MDA to Enterprise Computing, Willey Publishing Company, 2003

[39] OMG, A UML Profile for Enterprise Distributed Object Computing, Joint Final Submission, Part I and II, July 2001

[40] Schallbruch, M.: e-Government – Das neue Gesicht der Behörden, Vortrag eGovernment meets BundOnline, Speech held May 28th, 2002 in Berlin

[41] Accenture: E-Government 2003, Ergebnisse einer internationalen Vergleichsstudie, http://www.accenture.de/static_pdf/st_pdf_egovernment_0603.pdf

[42] Accenture: Anspruch und Wirklichkeit: E-Goverment in Deutschland, http://www.accenture.de/static_pdf/a-egov.pdf

[43] Accenture: eGovernment, Dem Fortschritt verpflichtet, http://www.accenture.de/static_pdf/st_egov_fortschritt_0102.pdf

[44] Arthur Andersen: EGovernment, Anwendung der neuen Informations- und Kommunikationstechnologien in der öffentlichen Hand, 2001

[45] Object Management Group, UML Profile for enterprise distributed Object Computing (EDOC), http://www.omg.org/technology/documents/formal/edoc.htm


Version V1.0 15.03.2004 - /93 -

Annexes


Version V1.0 15.03.2004 - /93 -

Annex A DETAILED DESCRIPTION OF RELEVANT PROJECTS

A.1 Project VeZuDa

During the recent years a large number of software products and systems have been developed and brought into operation in the Berlin City Administration (for short BCA in this text). Therefore the BCA had the same problem as industrial enterprises some time ago namely to integrate the existing systems to ensure cost efficiency and optimal usage and processing of the available data. But all the systems cannot (always) be interconnected, so that in spite of a modern and up-to-date technical infrastructure no encompassing and satisfying communication infrastructure exists.

The aim of the VeZuDa project was to develop and to implement a concept to overcome the missing access to data and information in the BCA. The large areas of stored data, separated and managed by different administrative units should be made available inside the BCA, as long as this is technically possible and legally allowed. Additionally a modernized IT-infrastructure should be installed to support development und implementation of services faster and easier. Re-use of services or components of services was one of the main requirements within the project.

Strategy

Starting from a common understanding of service provisioning this paradigm was transferred to public administration. This approach is obvious if the term product is replaced by complex services of public administration. The known chain from the ISO 9000 standard with "customer – product – supplier" is mapped on "citizen – administrative service – administration". Administration internal processes can be mapped by the same way.

On basis of this simplified service model a concept was defined. Within this concept the architectural framework is based on the Reference Model of Open Distributed Processing (RM-ODP), modeling and design is based on object-oriented technology and realized with UML the Unified Modeling Language. Real life technology is supported by standardized middleware (CORBA, Common Object Request Broker Architecture) while J2EE was still not available. All this was mixed up with an incremental, iterative procedure for the development process, described by the following picture.

citizen / industry

Product 2

Office IT- Service- provider

appliedtechnology

Administration

Requirements

Requirements

Requirements

Product 1

Figure 9: Development Process

Solution

A few requirements have been defined for the VeZuDa infrastructure. To protect the investments all decisions were targeted on a reliable, economic and secure technology for the next years. This includes cost effectiveness and economic efficiency, better adaptability, reduced cost for maintenance


Version V1.0 15.03.2004 - /93 -

and a better structure of administrative information. To achieve these requirements there was no alternative to object oriented technology. With this approach it was possible to model the business processes, the data and the underlying systems. There was no gap that had to be filled by any other paradigm.

The development of the VeZuDa system is based on the following well-known concepts out of the context of object orientation:

• Multi-Layer, Component-based Client/server Architecture Components at this point of time have been seen as units being used in the context of re-use, exchangeability as well as structuring method of the design process. The interfaces of the components were most important parts for all development work – the concrete implementation behind was exchangeable as long as syntax and semantics was maintained. The Client/Server approach was unavoidable to allow communication of objects/components not residing in common memory of a single process.

• Distributed, Heterogeneous Systems Concepts of integration environments for distributed, heterogeneous systems allow an easy communication of potentially distributed objects by means of an abstraction mechanism to disburden a developer from knowing location, language, operating system and hardware of a called object.

• Integration of Data by Capsulation To publish and to grant access to data which have been accessible only in local, autonomous environments by an integration environment the concept of capsulation offers an approach that allows the access to data by keeping the autonomy of the data owner.

Technical Base

The technical solution is based on a business model borrowed from concepts of the TINA Consortium. It identifies and supports the set of roles described in the following picture. These are roles that can be filled out in the context of electronic markets by relevant organizations and individuals.

B ro ker

C o n n ec tiv ity P ro vid er

C o n su m er

R tR *

R e t*

3P ty S erv ice P ro vid er R e ta ile r

3P ty*

3P ty*

R et*: R e ta ile r re fe rence p o in t (R etR P ) R tR *: R eta ile r to R eta ile r-refe ren ce p o in t 3P ty*: 3 rd P a rty -P ro v id er-re fe ren ce po in t

re levan t ro les in th e co n tex t o f V eZ u D A ad d ition a l ro les

Figure 10: VeZuDa Business Model

This technical basis generalizes the aspects originally developed for the telecommunication area:

• The Retailer sells various services to his customers. He sells services of his own, services of other providers. He can act as a broker to services other provider, combine them, enhance them and offer these value added services to his customers. He uses the transport service of a network provider.


Version V1.0 15.03.2004 - /93 -

• The Third Party Service Provider offers his services to Retailer and other Service Provider. He can use himself services of other Service Provider to built up his services. He uses the transport service of a network provider.

• The Customer closes a deal with a Retailer to use one or more of the available services. He uses the services by himself or delegates the usage to other persons.

• The Broker offers to Customer, Retailer and Service Provider information about available services in his area and if necessary mediates services between his clients. He is in a position to use services of other Brokers.

• The Connectivity Provider offers network transport services. He can cooperate with other Connectivity Providers and his service is used by Retailer and Service Providers to realize their own services.

By this general approach of the role model it was possible to map the roles of the administration and of the corresponding business model to these roles.

Architecture

By the deployment of dedicated middleware in VeZuDa a separation between service-specific and service-independent components could be realized and the cooperation with other CORBA-based applications and systems across domain borders was possible.

Three different types of services have been identified to describe service-specific issues. Data-Services and Integration-Services enable access to data and business processes. Information systems made use of these services and present them to the customer by use of an appropriate front-end. All the services can be maintained by the VeZuDa environment.

Customer-Domain VeZuDa-Domain Retailer-Domain

Informationssystem VeZuDa-Platform

D-IntegrationService

Provider-Service

InfrastrctureService

M-DataService

Figure 11: VeZuDa Environment

The VeZuDa-Environment or platform manages services and their profiles as well as customers with their contracts about services they want to use. Access to services (Provider-Service) is via the platform where access rights are evaluated and services set up for usage.

Additionally a set of service independent infrastructure services is available e.g. accounting service, security service, logging service, etc.

The M-DataService realizes access to specific data. M-Data is technical and organizational grouped data. Within VeZuDa an independent interface was specified which has to be implemented by each M-DataService to grant access to the data abstracting from file systems, databases, directories, etc.

The D-IntegrationService implements the business process as a whole or a fraction. Access to the necessary data is made by one or more M-DataServices. D-IntegrationServices can cooperate among each other to provide the required information.


Version V1.0 15.03.2004 - /93 -

Information systems provide access to government services. They form the presentation layer. In VeZuDa aggregated information was build up by D-IntegrationServices to provide this information also to other information systems to enable re-use of data.

Requirements for a service environment

An infrastructure to support all the needs has to fulfill basically the following requirements and must offer these functions:

• a runtime environment for objects

• mechanisms for service management

• access management

• user and rights management

• logging services for statistics and surveillance

• deployment service

• management and configuration

Advanced service of an infrastructure:

• digital signature management

• certificate handling

Additional services of general interest in the context of e-Government might be:

• a form service

• a call centre service

• a contract/request tracking service

• a cash and accounting service

Specific services of administrational units

• e.g. Geo Information and Data

The last five services will not be offered by commercial environments/infrastructures and have to be implemented as generic, reusable e-Government services. A forms service and a cash and accounting service have been implemented in two projects of the Berlin City Administration, because these services were the most requested by various administrative units. So VeZuDa offers in Berlin at the moment a basic infrastructure, a set of additional services and administrational services for internal and external usage by the city of Berlin.

A.2 VeZuDa Application - BLIS

BLIS is a service of the Berlin City Administration built on the concepts and technical results of the VeZuDa project. BLIS offers access geospatial data of real estate affairs, information about ownership, regional development plans and cost overviews.

This service fulfils two functions, on the one hand the integration of distributed available data and the combination of therein contained information and on the other hand the provision of a user-friendly portal with intelligent search and application functions making BLIS a value added information service.

The distribution of the data accessed by BLIS and the autonomy of their owners leads to a complex structure of customer/provider relationships. Besides these relationships BLIS has to deal with a set of


Version V1.0 15.03.2004 - /93 -

district domains with different organizational structure, access rights and roles. The VeZuDa architecture and environment was chosen to handle all the requirements.

VeZuDa recommends a general business model which has to be refined according the actual parameters of the BLIS universe of discourse. The architecture BLIS proposes looks like as in the following picture and is very close to the VeZuDa reference.

Dataservice

DS a DS b ... DS t

Integrationservice

IS u IS z

Services

Informationssystem Portalservice

...

Figure 12: BLIS Access

Access to BLIS is by a top-level service offering an information service based on standard web technology. The information system makes usage of two services: the integration services and data services where integration services re-use data services to aggregate and combine low-level information. Data services have a uniform interface to its outside and realize access to database systems by different access methods. This approach abstracts from underlying data storing technology and simplifies the usage of these components. Integration services are used to do a complex processing on data, which can't be realized inside data services. Therefore they made use of data services but they don't have to do so. Integration services can implement their own functions without accessing any other components in which case the name might be misleading. The BLIS instantiation of the model above is as follows.

client

BLIS - Portal

open service platform

governmental data

ALK ALB RBS

GAB FNP BRW provider

user customer

carrier

portal productmaster

search result

client

BLIS-Portal

open service platform

governmental data

ALK ALB RBS

GAB FNP BRW

governmental data

ALK ALB RBS

GAB FNP BRW

search result

Integration Service

legend • BRW: guide value of real estate

PC system

• FNP: planning of real estate use UNIX system

• GAB: map of assigned commercial areas PC system

• ALK: real estate map (vector based) geographical information system, mainframe & UNIX system

• ALB: real estate book mainframe system

• RBS: statistic information system mainframe system

Figure 13: BLIS Architecture


Version V1.0 15.03.2004 - /93 -

The abbreviations of the used databases refer to information (maps, addresses, etc. of the Berlin City Administration), which is combined to answer client requests. The BLIS integration service and the data services are implemented as independent CORBA server. This allows the distribution on different hosts in different domains. Data services are placed as near as possible in the domain of the corresponding data storage for self-evident reasons.

A.3 Discourse Support System - ZENO

The ZENO system, an Open Source groupware application for the Web written in Java, has been designed specifically for use as a discourse support system. This includes managing both the communities of users and groups who participate in the discourses and the content, which is created and used in the discourses. A simple but powerful role-based access control scheme connects the two functional parts of ZENO: users and groups managed by the directory service are assigned access roles in journals where the content of discourses is stored. Discourse management functions for session management and event monitoring (logging, notification, discourse awareness, etc.) as well as communication services (messages to users and journals) provide the necessary support during a discourse. ZENO’s features are implemented in an extensible object-oriented system architecture with easily customizable user interfaces, using the Velocity template engine and Cascaded Style Sheets.

The design goal of ZENO led to a simple but general data model with a rich set of data structures and operations. The core of this data model is a persistent content store for hyperthreads of journals, articles, topics and links. Journals are container-like objects that can be used for many purposes, including shared workspaces, discussion forums, calendars, task management, as well as a collaborative editing environment for complex, structured documents and content management. The contributions to a discourse are stored as articles. Topics are thematic collections of articles. Journals support both the threaded and the linear (topic-oriented) style of discussion. Typed links allow resources to be connected.

Operations of the data model include full text search and powerful support tools for moderators: moving, copying, deleting, publishing and unpublishing the articles, opening and closing topics, ranking or ordering articles and journals, as wells as labeling articles and links to visualize the relationships.

Journals are composed of a partially ordered sequence of any number of resources. Topics are composed of partially ordered sequence of any number of articles. Articles are composed of any number of attachments. An attachment can be a file of any MIME type (ex. word processing document).

ZENO includes a directory service for managing users and groups of users. The directory maintains passwords, contact information, in particular email address and user preferences. The directory can also be using for mailing lists.

For security and administration purposes, the directory is partitioned into a set of subdirectories, called community directories. A community directory can be configured so as to allow new users to register themselves in the community directory, without assistance of an administrator.

Access rights are controlled in ZENO by assigning the roles of reader, author or moderator to users and groups for each Journal. That is, these roles are assigned for journals but not directly for articles, topics and links. The access rights for an article or topic are those of the journal, which immediately contains the article or topic. The access rights for a link depend on the access rights for the source of the link.

The rights of each role are fixed by the ZENO system. Users cannot redefine them. Moderators have the most rights (with few exceptions they may do anything which can be done with a journal and its contents). Only moderators of a journal may create subjournals. The readers of a journal may access and view every article in the journal that is published. Like moderators, readers may also access and view the identifiers and titles of subjournals. Further rights to a subjournal are controlled by the roles defines in the subjournal. The authors of a journal have the right to create new articles and topics in the journal. Participants in a discourse will often be both readers and authors.


Version V1.0 15.03.2004 - /93 -

A.4 ZENO Application - DEMOS

One of the many successful applications of the Zeno was the use as a part of the foundation of the DEMOS system (http://demos-project.org). DEMOS stands for Delphi Mediation Online System and was an e-democracy research and development project founded by the European Commission (IST-1999-20530). The DEMOS system offers innovative Internet services facilitating democratic discussions and participative public opinion formation. The main goal is to reduce the distance between citizens and the political institutions by providing a system for moderated discourses involving thousands of participants about political issues at the local, national and European level. The vision of DEMOS is to motivate and enable all citizens to participate actively and effectively in political processes. On this way these processes become more democratic and more efficient than current practice.

Three phases of discussion are supported by DEMOS system: broadening, deepening and consolidating the discussion.

Figure 14: Phase model of DEMOS system

In the broadening phase the discussion is initiated and information about the problem situation and the interests, positions and ideas of the stakeholders are gathered from as many sources as possible. The moderators are supported in this phase by the system with tools to help with clustering and structuring discussion forum articles and visualize relationships among them. The result of this phase is an outline and summary of the discussion thus far. The second phase addresses selected issues in depth. For this purpose, the DEMOS system provides tools for helping the participants to break up into sub-groups, for conducting online surveys, and for collaborating on the formulation of joint position statements. The third and final phase is about consolidating the results from the subgroups into a document summarizing and visualizing the main points of the discussion. Ideally, this structured discussion process can lead to political consensus.

To evaluate the viability of the novel approach taken in the DEMOS project, four real world online trials were planned with the two prototype systems developed in the project. The technical system and the underlying methodology have been successfully tested in the cities of Hamburg and Bologna. The second test in the City of Hamburg in November 2002 has to be seen as one of the largest and most successful experiments in the domain of online democracy ever conducted on a municipal level.


Version V1.0 15.03.2004 - /93 -

Annex B DETAILED DESCRIPTION OF RELEVANT SUPPORTING INFORMATION

B.1 Germany – e-Government Manual

As the subject of e-Government is many-sided and technology is changing all the time, the e-Government Manual [11] was designed as a manual made up of various individual modules. Such approach allows more flexibility by supplementing and updating the manual. The manual itself consists of seven independent modules: Awareness raising, Basics, Phase Plan, Main topics, Specifications and Solutions, Additional resources, Legal basis.

For eGOIA the manual is interesting in parts, because it is part of the reorganization of structures and processes of the administrative authorities, which must accompany the information-technological solution. This includes in particular actions of the public authority towards business processes, the introduction of information and a knowledge management, a new kind of the personnel management and the development as well as the orientation towards the needs of the customers.

Module I – Awareness raising

The first module of the manual contains only one document: “Top priority e-government: guidelines for heads of public agencies”, in which the following aspects will be addressed.

The goals:

• Connection of all online-capable administrative services to the Internet

• Introduction of intranet within the authorities

• Business process without medium break

• Reduction of costs

• Influencing of quality and quantity of the business processes.

The introduction of e-Government takes place in following steps:

• Creation of e-Government-coordinators or teams

• Design of the e-Government-Strategy

• Realization in form of a phase plan

• Investigation and registration of the existing workflows and processes

• Further training of the employees

• Equipping of the employees with work stations

IT requirements:

• Reliable, available, flexibly, expandable

• Modular, platform-independent

• Standardized data formats

• Data protection and data security.

Module II – Basics


Version V1.0 15.03.2004 - /93 -

The second module is composed of four documents: “Encryption and signature”, “Classification scheme for e-government procedures”, “Legal principles for e-government” and “Data protection in e-government”. The security aspects will be addressed in a separate chapter, so we focus on the classification schema.

The authors differentiate two essential characteristics: the customer- and the IT-view. The dimension of the customer view is divided into pure information offers, over it going general services as well as individual services. The dimension IT view is partitioned in with a medium break afflicted, without medium break as well as fully automatically carried out processes. From this organization results a two-dimensional classification pattern, in which existing and future e-Government-procedures can be arranged in nine different classes.

Module III - Phase Plan

The phase plan serves the support of the projects manager concerned with the introduction of e-Government. The plan contains a six phases, described in six separated documents: “Phase 1 – Initialization”, “Phase 2 – Strategy”, “Phase 3 – Analysis”, “Phase 4 – High-level Design”, “ Phase 5 – Implementation and tests”, “Phase 6 – Introduction and initial operation”. Additionally, there is an extra document containing an illustrative example of the Phase Plan (“Introduction of e-Government at the fictitious Federal Office for on-line services”).

Module IV – Main Topics and Module V – Specifications and Solutions

The fourth module treats two themes, which are divided into extra blocks: “Requirements and quality assurance” and “IT and IT security”. A separate chapter will cover the security aspects. The first block describes in four documents (three of them are final) particular aspects of evaluation criteria for potentially online-capable service, quality criteria for citizen friendly and secure web presence as well as particular e-commerce aspects could be needed by public agencies (e.g. in case of charging a fee online).

The fifth module consists of four separate blocks:

• “Standards and specifications” – describes the standards, processes, methods and products of state-of-the-art IT development for e-government applications (“SAGA – standards and architectures for e-government applications”, newly in version 2.0),

• “Guidelines” – contains only one document describing a guidelines for the conception and realization of an Internet-based selling platform (only German version available at the moment),

• “Platforms” – introduction of existing network infrastructure of public administration that can be used for e-government; as well as the functional characteristics, the security characteristics of the networks are also described,

• “Practical examples” – this block consists of a set of documents describing the e-Government model projects currently carrying out in context of BundOnline2005 initiative etc.

Module VI – Additional Resources and Module VII – Legal Basis

The last two modules won’t be covered more detailed, because they are not before large interest. The sixth module contains a “Glossary”, description of a set of tools and resources for e-Government (grouped under the title “Toolbox”, e.g. “USEIT tool – Secure UNIX Administration”) and selected studies (grouped under the title “Selected Studies”, e.g. “Apache-webserver security study”). “Legal Basis” (available only as print version) deals with all legal aspects in context of e-Government.

B.2 USA: e-Gov Enterprise Architecture Guidance

The Federal Enterprise Architecture (FEA) being developed by the Office of Management and Budget (OMB) (www.feapmo.gov) is a comprehensive, business-driven framework for changing the Federal


Version V1.0 15.03.2004 - /93 -

government’s business and IT paradigm from agency-centric to Line-of-Business (LOB)-centric. The FEA includes five reference models:

• Business Reference Model (BRM)

• Performance Reference Model (PRM)

• Service Component Reference Model (SRM)

• Data and Information Reference Model (DRM)

• Technology Reference Model (TRM)

Figure 15: FEA Reference Model

The FEA reference models create a government-wide framework to: (i) guide agency IT investment activities; (ii) identify opportunities to collaborate on and consolidate initiatives; and (iii) integrate government activities.

The BRM is a framework for describing the business of the Federal Government independent of the agencies that perform it, and serves as the foundation for the FEA. The model describes the Federal Government’s Lines of Business, including its internal operations and its services for the citizen, independent of the Agencies, bureaus and offices that perform them. By describing the Federal Government around common business areas instead of the stove piped, agency-by-agency view, the BRM promotes agency collaboration.

The PRM is a framework for performance measurement that provides common outcome and output measures throughout the Federal Government. It allows agencies to better manage the business of Government at a strategic level while providing a means for gauging progress towards the target FEA. The PRM accomplishes these goals by establishing a common set of general performance outputs and measures that agencies use to achieve program and business goals and objectives. The model articulates the linkage between internal business components and the achievement of business and customer-centric outcomes. Most importantly, it facilitates resource allocation decisions based on comparative determinations of which programs/organizations are more efficient and effective.

The SRM is a business-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives. The SRM is structured across horizontal


Version V1.0 15.03.2004 - /93 -

service areas that, independent of the business functions, can provide a leverageable foundation for reuse of applications, application capabilities, components, and business services.

The DRM, still being developed, will describe, at an aggregate level, the data and information that support program and business line operations. The model will aid in describing the types of interactions and information exchanges that occur between the Federal Government and its various customers, constituencies, and business partners. It will categorize the government's information along general content areas specific to BRM sub-functions and decompose those content areas into greater levels of detail, ultimately to data components that are common to many business processes or activities. The DRM will establish a commonly understood classification for Federal data and lead to the identification of duplicative data resources as well as enable information sharing between agencies. A common data classification model will streamline the processes associated with information exchange both within the Federal government and between the government and its external stakeholders. The DRM will be produced on a business line by business line basis, as opposed to a single cumulative effort. This allows for the identification of and concentration on key improvement areas, producing clearly identified and measurable results. The FEA-PMO will oversee the focused DRM efforts to ensure all appropriate points of integration are identified. Additionally, they will help identify reusable data components that support a Line of Business and/or Sub-functions. Attributes of these data components will be based upon specifications as identified in the FEA Technical Reference Model, and accessed by a specific Service Component.

The TRM is a hierarchical foundation used to describe how technology is supporting the delivery of Service Components and capabilities. The TRM will outline the technology elements that collectively support the adoption and implementation of component-based architectures, as well as the identification of proven products and toolsets that are embraced by government-wide initiatives such as FirstGov.Gov, Pay.Gov, and the 24 Presidential Priority e-Government Initiatives.


Version V1.0 15.03.2004 - /93 -

Annex C DETAILED DESCRIPTION OF RELEVANT TECHNOLOGY

C.1 Service Integration Platform - EnagoOSP

Overview

The e-Government Masterplan Berlin required an administration process independent IT-infrastructure, which is able to offer electronic services as online services, provides uniform access such as one-stop-shop, allows for service offering according to real demands and supports outsourcing to handle Public Private Partnership. More details can be found in A.1.

The enago Open Service Platform (enagoOSP) provides a uniform service access, execution and management environment, particularly across different administrative and technological domains. It is based on state of the art CORBA and Java 2 technologies that enables component based e-service and service portal implementation. enagoOSP has been designed to support efficiently and economically the different roles involved in e-Government, namely end users/citizen, government offices, infrastructure providers and third party providers by the provision of a unique service integration platform.

The main focus of enagoOSP is to enable the integration, composition and management of existing and emerging application services based on different programming languages, different access technologies and different service technologies, and to provide a controlled (secure) and uniform access to these services by means of one-stop shopping and single sign on capabilities including customization by means of profiles to the customers and end users.

Phone

Internet

Fax

E-Mail

HTML / XML / WML

Service Access eGovernment Platform Content Provider

Legacy System Integration

Service Components



Service Integration

enago core Access

& Delivery

Content Adapt.

Service Components Service Components

3rd Party Service

Provider 3rd party

Access

G2C G2G & G2B

Application Frameworks

Toolkit: development, deployment, configuration, administration

Mobility Support

Figure 16: EnagoOSP architecture


Version V1.0 15.03.2004 - /93 -

Technology Integration

EnagoOSP integrates different access technologies and service technologies in a comprehensive service provisioning architecture. The platform supports a variety of access technologies including Java Applets and Servlets in combination with CORBA-IIOP or Java-RMI and HTML pages in connection with HTTP, etc. In addition, access is optionally enabled via fixed and mobile voice and data networks.

Services can be realized with a variety of software technologies, e.g. services implemented in C++ or Java, with EJB or other component technologies. Standardized protocols used inside generic service development frameworks allow changing different implementations of a service dynamically without affecting the service interfaces. Analogously, a single service implementation can be accessed via user interfaces realized with different technologies. enagoOSP provides adaptors that serve as a protocol translator between the CORBA-IIOP protocols used for coupling to the platform and the service-specific protocols.

Business Model

The business model required by the government is described below.

• GovernmentToCitizen - support the integration of public services from a citizen’s/customer of public services point of view

• G2B GovernmentToBusiness - support communications with organizations relying in their business on information provided by administration, e.g. Bank, Insurance companies, Churches,

• G2G GovernmentToGovernment - exchanges between different branches of administration

Figure 17: e-Government Business Model

The enagoOSP platform provides a flexible role model allowing to register and administer citizen, users, public servants, service providers, and operators etc. within the framework of subscription, which are offered as administration services.

enagoOSP Components

enagoOSP Kernel

Universal framework for the administration of services and customers, based upon the stakeholder model of enagoOSP. It enables the definition and monitoring of service-specific contracts between retailers and subscribers. Groups of users with the same rights can be handled in subscription assignments groups (SAG). Each user or user group can be assigned specific rights in respect to service usage and accounting, independent of the service-specific aspects. Either an object oriented database or a relational database may be used to store the data.


Version V1.0 15.03.2004 - /93 -

EnagoOSP Access

This comprises the realization of the concepts of a technology independent access session for service subscribers. It enables the start of a new service session or the joining of an existing session. For each user, a specified amount of personal data, authentication information, and service-specific preferences is stored. The personal data is collected as part of the subscription process; the service-specific profile is installed within the framework of service usage. The access component is responsible for the identification and authentication of users. It supports the administration of active service sessions, and user profiles, plus supports the start of a new or the joining of an existing service session.

Enago Portal

Universal interface for access to enagoOSP informs the user about available services, sessions and invitations; initiates the start of any service interface. The service access occurs on the user side via a previously installed or dynamically loaded user interface based upon Java/CORBA or the purely Internet-based HTML/HTTP. The concept of the portal includes an internal interface that separates the pure user interface. A variety of technologies for user interface design (Java, HTML, speech) can be implemented via this interface. It is also possible to offer the user interface with a variety of behaviors. For this the operations offered are collected in different groups. For example, a complete portal can inform the user about all the state changes within enagoOSP while a limited portal designed especially for a specific service might receive this information without making it visible to the user.

One-stop-shop/Single-Sign-On

Access to services provided by enagoOSP is based on the session concept, i.e. a service user has to identify and authenticate himself within a so-called access session prior to the service usage (service session). The main principle here is the single-sign-on principle, i.e. the user has to authenticate only once during the access session and can subsequently use all the services for which he has the usage rights (as a result of signing corresponding contracts with the provider) without any additional authentication procedures. This means that after selection of an appropriate service, the platform authenticates the user automatically for the subsequent service session.

Runtime Environment

The interaction between service components in enagoOSP is supported by the provision of distributed processing mechanisms supporting the life cycle of components. Via the respective service interface, special interfaces can be addressed that enable the installation, manipulation and deletion of entities identified within the enago information model. A CORBA based distributed processing environment has been developed that serves as a runtime system for enagoOSP or as a container for the platform components. These components can be configured, controlled and monitored.

Security

Last but not least, enagoOSP as a user, customer and service administration platform places a major emphasis on inherent security support. enagoOSP provides the following capabilities:

Identification and Authentication of users by means of:

• Smart-cards, and software certificates, which can be verified by an external PKI

• Encryption and assurance of integrity of:

o Information exchanged between users and enagoOSP services

o Information exchanged between enagoOSP components, and

o Information exchanged between federated and distributed OSP systems

• Usage of SSL for communication security in the Internet (HTTPS) and within intranets (IIOP over SSL)


Version V1.0 15.03.2004 - /93 -

enagoOSP Services

Administration Services

The service platform itself provides a number of services for the administration of users, subscribers, retailers, service providers, services and service contracts.

a) Administration service for operators

This service allows the manipulation of all entities that are identified in the enagoOSP information model. The service will be used during the maintenance of the platform.

b) Administration service for User

The user administration service is available for cases in which an organization with several users acts as a subscriber in a relationship with a retailer, or for cases where the retailer administrator installs subscribers and users offline.

If a registered subscriber wishes to allow several users access to a service in his name, then this state must be installed in the retailer domain. For this the subscriber requires authorization to use or to entitle a user to use the user administration service. This service permits:

• User administration, meaning installation, manipulation and deletion of users,

• Administration of user groups,

• Entitlement for the user to use subscribed services by assigning service profiles to user groups and individual users.

c) Online Subscription

The online subscription service (OLS) is provided by enagoOSP as a generally available service and can be installed with context-specific interfaces. There are different versions of the online subscription depending upon, whether or not the user is registered, and whether or not the user is a privileged user, who may subscribe to new services for his subscriber organization.

The following OLS variants are available via enagoOSP:

• Online registration for an anonymous user (guest),

• Online subscription for a registered user,

• Subscriber and user administration,

• Service administration.

Profile Service

Profiling is an important feature for customized service provisioning. A corresponding profile component provides services with access to the service and user-specific information contained in the administrative components of enagoOSP i.e. information about the user (user profile), user-specific service attributes (user service profile) and common or specific service attributes (service template properties, service profile).

Beyond this, components also support access to the available services via an access gate, whereby a user-specific and service-specific profile mechanism is provided.

Service Composition and Federation

Services that do not use of CORBA can be easily connected to the platform administration services by means of corresponding adaptors. This enables for example the integration of legacy services as well


Version V1.0 15.03.2004 - /93 -

as services implemented by means of other state of the art middleware technologies, such as EJB, .NET and others.

The principle OSP role model permits the definition of chains of service-usage contracts – the retailer-consumer model. Corresponding reference points including appropriate interfaces and protocols have been designed to ensure that any number of services from different providers can be combined within a uniform business model. Transparent to the end user, the decision to use a service from a provider can lead to the expansion of a complex network of access sessions, some of which may need to be especially established, and a chain of service usage among different service providers.

To couple different enagoOSP instances or to connect legacy and other service platforms to enagoOSP specific mechanisms for the composition are provided in the service framework. These techniques allow a service to be started from within another service. The use of the available authentication and authorization mechanisms enables the use of services within the retailer domain as well as services within other provider domains, while taking into consideration the control mechanisms provided by the platform.

Service Frameworks

The platform provides corresponding development frameworks in form of C++ and Java libraries, which hide the details of CORBA/RMI interfaces of the platform towards the application developer. Currently the main frameworks provided enable service access, service session management, profile management, service composition and federation, and service monitoring.

In summary this means that different services, which are implemented in different technologies, such as C++, Java, EJB and other component technologies can be uniformly administrated by enagoOSP. The use of dedicated protocols standardized within the service frameworks enables the dynamic exchange of service logic implementations without effects on the user interface parts and vice versa.

enago FW (Java)

Application Applet Servlet

enago FW(C++)

Service 1GUI

Service 1GUI

Service 1Server (Java)


Service 2Server (C++)


Service 2 GUI

Service 2 GUI

CPE Domain Retailer Domain

enago FW(Java)

EJB

Core Frameworks

enago FW (Java)

Application Applet Servlet

enago FW(C++)

Service 1GUI

Service 1GUI





Service 2 GUI

Service 2 GUI

CPE Domain Retailer Domain

enago FW(Java)

EJB

Core Frameworks

Figure 18: Service Development Support through Development Frameworks

C.2 Tools for Service Creation

Based on OMGs MDA compliant approach for the rapid definition and development of software systems a modeling infrastructure is available, that supports the software development for enagoOSP based on UML, EDOC, and MOF. This Modeling Infrastructure contains modeling and development tools and their interconnection. Each of these tools or modeling techniques supports a different phase or activity in the development process for a software system, i.e.


Version V1.0 15.03.2004 - /93 -

• The platform independent modeling tools based on UML and EDOC directly support the abstract PIM and refined PIM modeling steps,

• The PSM modeling tools based on UML and a UML profile for enagoOSP support the enagoOSP platform specific modeling tasks,

• The integration between the MDSC Modeling Infrastructure and eclipse does support the final Java developments and compilation of system components and finally,

• enagoOSP supports the integration of these components, their operation and the maintenance of the resulting system.

Figure 19: Tool-supported Development Process

One can see that each of the tools alone supports a particular task in the system development process. On the one hand, the mentioned tools are connected to this infrastructure. This connection is technically being achieved using defined metamodels for the modeling technique supported by a tool and by applying the MOF compliant medini tools to generate model repositories out of these metamodels. These repositories store models defined using these tools, and allow other components to access these models. The model repositories exist for platform independent models (based on EDOC metamodels), for enagoOSP platform specific models (based on enagoOSP metamodels) and for system components (based on the Java metamodels).

On the other hand, model transformers transform between the various models stored in the repositories. Model transformers

• from EDOC models to enagoOSP models and

• from enagoOSP models to Java code

have been developed. These model transformers connect to a source repository, read the source model, apply transformation rules and store the resulting model in the target repository. They have to a large extend been generated out of the source and target metamodels. A developer just has to add the transformation logic to the generated transformer skeletons. The skeleton takes care of ordering


Version V1.0 15.03.2004 - /93 -

and priority issues, connects the transformer to the repositories – and calls the provided transformation logic at the right point in the transformation process.

Figure 20: Modeling Infrastructure