„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии

SAGA
Standards and Architectures for eGovernment Applications

Version 4.0

March 2008

2 SAGA 4.0

Reprint, even in part, subject to approval

This volume was prepared by the Federal Ministry of the Interior
in co-operation with ]init[ AG and
Fraunhofer-Institut für Software- und Systemtechnik (ISST).

Homepage and download of the digital version: http://www.cio.bund.de/saga

mail to: IT2@bmi.bund.de

SAGA 4.0 3

SAGA
Standards and Architectures for eGovernment Applications

Version 4.0

March 2008

Published by
the Federal Ministry of the Interior

SAGA 4.0 5

Word of thanks

The Federal Ministry of the Interior and the SAGA authors would like to thank the
representatives from the federal states and municipalities in the KoopA-SAGA project
group, the representatives from the central IT service providers of the federal
administration along with all the members of the SAGA expert group for their support
during the preparation of this version of SAGA.

We would also like to extend our thanks to all those who have made use of the SAGA forum
and the SAGA contact form and whose committed comments constituted a valuable
contribution towards updating the document.

6 SAGA 4.0

Introduction:

This document presents in concise form widely used standards, processes, and methods of
state-of-the-art IT development for eGovernment applications. Due to the nature of this
subject, experts in this sector use many abbreviations and, in most cases, English acronyms.
Some of these names are protected by copyright and/or are registered trademarks, or are
products of certain manufacturers or standardization organizations that are protected at
national and international level.

In the interest of a simple structure, copyright and source references of this kind were
generally omitted. The use of a "name" or abbreviation in this document does not
mean that they are free from copyrights or intellectual property rights of third
parties.

Furthermore, neither the editor, the authors nor the experts consulted can accept any
responsibility for the technical functioning, compatibility or completeness of the standards
discussed. This version 4.0 was published in October 2007. Please send any comments,
amendments or corrections to: Bundesministerium des Innern, Referat IT2. These
comments, amendments or corrections can also be published on the SAGA forum at
http://www.cio.bund.de.

Version numbers are stated when they are relevant in the specific context discussed. If no
version numbers of standards are stated, the version which is most stable from a market
point of view should be used, even though this may not necessarily be the latest version.

The authors permit the further use of this document - even in part - on condition that it is
quoted as the source.

A general demand for SAGA conformance is not enough in order to achieve the
goals of SAGA. Due to the complexity of the document, a general demand leaves too
much room for interpretation and misunderstanding. This makes it difficult for the
supplier to fulfil the requirements and for the customer to check that requirements are
fulfilled. To find out more about the correct handling of SAGA conformance, please refer
to section 2.4 on page 25, and for further assistance, go to: http://www.cio.bund.de/saga.

In the time since the first publication of SAGA 4.0 the website http://www.kbst.bund.de/saga
was moved to http://www.cio.bund.de/saga. Therefore some of the links given in this
document are no longer valid. For information on SAGA please refer to
http://www.cio.bund.de/saga.

SAGA 4.0 7

Table of Contents
0 Status, revision history and outlook..................................................................................................9
0.1 Amendments to version 3.0................................................................................................................9
0.2 Future issues.........................................................................................................................................10
1 Introduction..........................................................................................................................................11
1.1 Background...........................................................................................................................................11
1.2 Readers of this document...................................................................................................................11
1.3 Aims........................................................................................................................................................12
1.4 Tasks.......................................................................................................................................................12
1.5 Basic principles for eGovernment applications.............................................................................13
1.6 Relationships with other eGovernment documents.....................................................................13
1.7 The evolution process.........................................................................................................................17
1.8 Structure of the document.................................................................................................................18
2 Fundamentals of SAGA.......................................................................................................................19
2.1 Scope of validity and binding effect of SAGA..................................................................................19
2.2 Minimum requirements with regard to the openness of standards.........................................20
2.3 Classification and life cycles of standards.......................................................................................20
2.4 SAGA conformance.............................................................................................................................25
3 Architecture model for eGovernment applications......................................................................31
3.1 Overview...............................................................................................................................................31
3.2 Enterprise viewpoint..........................................................................................................................32
3.3 Information viewpoint.......................................................................................................................33
3.4 Computational viewpoint.................................................................................................................34
3.5 Engineering viewpoint......................................................................................................................34
3.6 Technology viewpoint........................................................................................................................34
4 Enterprise viewpoint: Fundamentals of eGovernment...............................................................35
4.1 Definitions of eGovernment in Germany.......................................................................................35
4.2 The philosophy underlying eGovernment.....................................................................................36
4.3 Strategic goals......................................................................................................................................37
4.4 Organizational requirements...........................................................................................................41
4.5 Legal frame of reference....................................................................................................................45
4.6 Processes in eGovernment................................................................................................................49
4.7 Modules for the implementation of eGovernment applications...............................................52
5 Information viewpoint: Standardization of data models............................................................55
5.1 Levels of interoperability...................................................................................................................55
5.2 Purpose of standardizing data models...........................................................................................56
5.3 The Deutschland-Online "Standardisierung" [Standardization] project.................................57
5.4 Support for data model developers.................................................................................................59
6 Computational viewpoint: Reference software architecture....................................................65
6.1 General requirements for software applications..........................................................................65
6.2 Implementation options and architecture paradigms................................................................67

8 SAGA 4.0

6.3 Reference software architecture for eGovernment applications...............................................72
7 Engineering viewpoint: IT service management and reference infrastructure.....................79
7.1 IT Service Management with the ITIL..............................................................................................79
7.2 Design of an eGovernment infrastructure.....................................................................................84
7.3 Networks as the link between an infrastructure and external services and users..................88
7.4 Access to external services................................................................................................................88
8 Technology Viewpoint: Standards for IT architecture and data security..................................91
8.1 IT security concept..............................................................................................................................91
8.2 Process models....................................................................................................................................95
8.3 Data models.........................................................................................................................................96
8.4 Application architecture...................................................................................................................98
8.5 Client....................................................................................................................................................101
8.6 Presentation.......................................................................................................................................105
8.7 Communication.................................................................................................................................121
8.8 Backend...............................................................................................................................................130
8.9 Encryption..........................................................................................................................................132
8.10 Electronic signature..........................................................................................................................133
8.11 Smartcards..........................................................................................................................................135
8.12 Long-term archiving.........................................................................................................................136
Appendix A References..........................................................................................................................................139
Appendix B Overview of Classified Standards....................................................................................................143
Appendix C Abbreviations.....................................................................................................................................153

SAGA 4.0 9

0 Status, revision history and
outlook
0.1 Amendments to version 3.0
This document is a revised version of SAGA, version 3.0. The following changes have been
made:

In chapter 2 "Fundamentals of SAGA", the names of the lists for the extended classification
of technical standards outside the document (White List, Grey List, Black List) were replaced
with new names (List of Suggestions, Right of Continuance List, Negative List)1.

Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" has been re-organized.
The terms "eGovernment" and "service" are now more clearly defined2. This chapter was
also extended to include the topics of "eGovernment 2.0"3, "Deutschland-Online"4,
"Germany as a member of the European Union"5, the "EU service directive"6 and the
"Federal government's signature projects and initiatives"7 .

Chapter 5 "Information viewpoint: Standardization of data models" was revised with a view
to the Deutschland-Online "Standardization"8 project and the topics of XGenerator 2.09 and
Core Components10.

Chapter 6 "Computational viewpoint: Reference software architecture" now also includes
sections on architecture decisions11 and information addressing the introduction of service
oriented architectures12.

Chapter 7 "Engineering viewpoint: IT service management and reference infrastructure"
introduces the "IT Infrastructure Library" (ITIL) as best practice for IT service management13.
In addition to this, the Deutsches Verwaltungsdiensteverzeichnis (DVDV) [German
Directory of Administrative Services] is presented in more detail14.

The previous chapter 8 “Technology viewpoint (part I): Standards for the IT architecture"
and chapter 9 "Technology Viewpoint (part II): Standards for data security" were combined

1 Refer to section 2.3.2 "Extended classification of standards" on page 21
2 Refer to section 4.1 "Definitions of eGovernment in Germany" on page 35
3 Refer to section 4.3.1 "eGovernment 2.0 – A Federal Government programme" on page 37
4 Refer to section 4.3.2 "Deutschland-Online - The joint eGovernment strategy of the Federal
Government, federal-state governments and municipalities." on page 38
5 Refer to section "Germany as a member of the European Union" on page 43
6 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48
7 Refer to section "Federal Government initiatives and projects in the field of electronic
signatures" on page 46
8 Refer to section 5.3 "The Deutschland-Online "Standardisierung" [Standardization] project"
on page 57
9 Refer to section 5.4.3 "XGenerator 2.0" on page 62
10 Refer to section 5.4.4 "Core components" on page 63
11 Refer to section 6.3.1 "Architecture decisions" on page 72
12 Refer to section 6.3.2 "Introduction of a service oriented architecture" on page 73
13 Refer to section 7.1 "IT Service Management with the ITIL" on page 79
14 Refer to section 7.4.1 "Deutsches Verwaltungsdiensteverzeichnis [German Directory of
Administrative Services]" on page 88

10 SAGA 4.0

to form chapter 8 "Technology viewpoint: Standards for IT architecture and data security".
Moreover, products and implementations were persistently replaced by the underlying
standards. The previous positive list of supported plug-ins was replaced by a list of
requirements which plug-ins should fulfil in the federal administration's eGovernment
applications. The topics of "IP telephony"15 and "Registries"16 were re-introduced and the
topic of "Smartcards"17, which was already addressed in SAGA 3.0, was dealt with in more
detail.

SAGA 4.0 no longer features a separate appendix for the one-for-all offers (OFA offers) by the
federal administration. The OFA offers will be soon described and will be updated outside of
SAGA on the KBSt18 homepage and/or on the homepage of the individual OFA offers,
respectively. The definitions of OFA service, OFA system, infrastructure and OFA concept
were moved to chapter 619.

Furthermore, this version also features a response to the further development of standards.
Standards were accepted from the List of Suggestions (former White List), the classification
of existing standards was changed and standards were moved from the document to the
Right of Continuance List (former Grey List20).

0.2 Future issues
The following topics are to be examined and dealt with in more detail in the next version of
SAGA:

a. Development and standardization of process and data models

b. IT service management on the basis of the "IT Infrastructure Library" (ITIL) v3.0

c. Long-term archiving of dynamic information from databases and websites

d. Communication per instant messaging and chat
e. Exchange and visualization of 3D data

Besides the SAGA document, the Federal Ministry of the Interior also provides additional
information, links and tools on the web21.

15 Refer to section 8.7.4 "IP telephony" on page 125
16 Refer to section 8.8.1 "Directory services and registries" on page 130
17 Refer to section 8.11.2 "Contactless smartcards" on page 135 and section 8.11.3 "Reader units
and interfaces for smartcards" on page 136
18 Refer to http://www.kbst.bund.de/efa
19 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76
20 With regard to the definition of White List and Grey List, refer to section 2.3.2 on page 21
21 Refer to http://www.kbst.bund.de/saga

SAGA 4.0 11

1 Introduction
1.1 Background
In an effort to create a more modern and service-orientated administration, the Federal
Government is implementing more and more administration processes electronically. The
application of eGovernment is making it possible for citizens, business and administrations
to handle matters both faster and more efficiently. Standards are needed in order to enable
these many different applications for the future and accessible for all. This is guaranteed by
the Standards and Architectures for eGovernment Applications (SAGA) guideline.

Shortly after the launch of the nation-wide BundOnline Initiative, the Co-ordinating and
Advisory Agency of the Federal Government for Information Technology in the Federal
Administration (KBSt) made this document available for the first time in 2002. Since then,
SAGA has been helping public agencies to achieve the goal of the initiative and to offer
more than 400 online services with Internet capability.

On the basis of this success, the SAGA expert group continuously accompanies work on the
standards. In this version 4.0, central IT service providers from the federal administration
were involved for the first time in updating the guideline. The latest developments and
experience are being added to the document through the discussion in the public SAGA
forum. In close co-operation with a KoopA-SAGA project group22, the specific requirements
of the federal states and municipalities are also being included. With this knowledge, the
SAGA authors regularly prepare an updated version with the Federal Ministry of the Interior
which is in charge of content.

A host of completed projects has now been orientated towards the state-of-the-art and
investment-safe standards and technologies recommended by SAGA. Many federal
agencies use SAGA to plan and implement their IT projects, so that they can shape the
interoperability of the various planned and existing applications.

Widespread acceptance and especially growing interest among federal states and
municipalities are proof that SAGA is becoming increasingly important for eGovernment in
Germany. In this version 4.0, SAGA once again offers a guideline for the economic and
future-orientated implementation of IT projects in administrations.

1.2 Readers of this document
SAGA is primarily designed for decision-makers in the fields of organization, information
technology and eGovernment 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.

22 KoopA ADV = Co-operation Committee for Automatic Data Processing for the Federal-
government, Federal-state Government and Municipal Administration Sector

12 SAGA 4.0

Application developers should feel free to seek further detailed solutions whenever the
standards and solution proposals presented herein are not sufficient for the
implementation of technical requirements.

The Federal Government also sees its initiative as a contribution towards the development
of eGovernment in Germany. The experience gained within the scope of the initiative
should help to promote nation-wide, inter-agency eGovernment offers.

1.3 Aims
SAGA pursues the following aims:

a. Interoperability – Warranting co-operation between various eGovernment
applications in order to effectively exchange information between the Federal
Government, citizens, businesses and partners of the Federal Government

b. Reusability – re-use of process and data models, systems, services and components in
various eGovernment projects in order to generate synergies

c. Openness – Inclusion of open standards in eGovernment applications in order to
promote their long-term usability23

d. Reduction of costs and risks – Considering investment-safe developments on the
market and in the field of standardization

e. Scalability – Ensuring the usability of applications as requirements change in terms of
volume and transaction frequency

1.4 Tasks
SAGA pursues a comprehensive standardization approach for Germany's administrations in
order to achieve the following goals.

Defining technical Standards and Architectures for eGovernment Applications
The technical standards and architectures cover all the levels and elements relevant for
eGovernment. They form the basis for the interoperability and compatibility of the
eGovernment applications to be developed.

Standardizing processes and data in administrations

In order to achieve interoperability and compatibility of eGovernment applications, it is
necessary to create a basis for standardizing processes and data in Germany's
administrations. In an effort to support this, systems and services are described on the KBSt
website which can be used as modules (one-for-all offerings24) in eGovernment applications.

23 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on
page 20
24 OFA offering and networks: http://www.kbst.bund.de/efa

SAGA 4.0 13

1.5 Basic principles for eGovernment
applications
eGovernment applications are designed to fully reach their target groups. This is why it
should be possible to access all the functions irrespective of the users' selected platform, the
configuration of the user systems or the abilities of the users. eGovernment applications
must be orientated towards the requirements and needs of the target groups.

On the basis of these preconditions, the following basic principles are laid down for
eGovernment applications:

a. eGovernment applications primarily use the web browser as the front-end, unless the
services to be implemented cannot be reasonably handled via a browser.

b. They do without active contents so that users are not forced to reduce the browser's
security settings and thus to make damage by invisible websites possible, or at least use
only signed and quality-secured applications of the type contemplated in the section
8.5.1 "Access to information with computers” on page 101.

c. eGovernment applications do not store any program parts or data on the users'
computers beyond the users' control25.

1.6 Relationships with other eGovernment
documents
Trials with standards and architectures for eGovernment have been underway for some
years now in Germany and in other countries26. Experience from these trials and
international exchange help make it easier to define and implement SAGA.

SAGA is published as part of the KBSt publication series which also includes, for example,
the "V Model XT", the "Migrationsleitfaden" [Migration Guide] and the "DOMEA-Konzept"
[DOMEA concept]. The documents of these series are adjusted to each other when updates
are released. This means that SAGA supersedes contents and information of older
documents and that new documents consider the contents and information of the latest
SAGA version. A broad-based co-ordination process accompanies any SAGA update in order
to avoid conflicts with valid documents.

E-Government-Handbuch [eGovernment manual]
In order to promote the Federal Government's eGovernment initiative – such as the
BundOnline 2005 Initiative that was completed in 2005 – and to support federal-state and
municipal agencies, the E-Government-Handbuch27 [eGovernment manual] is prepared
under the leadership of the German Federal Office for Information Security. This manual is

25 The automatic installation of software playing certain music CDs is one negative example
of non-requested saving of programs on computers.
26 Refer to the respective documents and publications in the UK [e-GIF], the United States of
America [FIPS-PUBS], Australia [APEC] and Europe [IDABC].
27 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm

14 SAGA 4.0

designed as a reference manual and central information exchange for issues related to
eGovernment.

The E-Government-Handbuch [eGovernment manual] is a modular compilation of material
that covers a broader range of issues and topics than SAGA. As far as identical issues are
addressed, the E-Government-Handbuch [eGovernment manual] does so in a more
concrete manner. This is why certain modules of the eGovernment manual are referenced
from within SAGA28. SAGA sets forth guidelines, whilst the E-Government-Handbuch
[eGovernment manual] explains the implementation of these guidelines and offers
practical advice.

In mid-February 2003, SAGA became part of the E-Government-Handbuch [eGovernment
manual]. It is the module of the manual with the strongest binding effect. All the other
modules are designed to ensure conformity with SAGA.

When examining the focal issue of "IT and IT security", the study titled "Sichere Integration
von E-Government-Anwendungen(SIGA)"29 [Secure integration of eGovernment
applications] was drafted. The aim of this study is to adapt the technologies presented in
SAGA for the business logic level, to identify correlations and to provide valuable,
independent assistance for IT experts and decision makers.

IT-Grundschutz-Kataloge und -Standards [IT baseline protection catalogues and standards]
In order to draft IT security concepts for normal security requirements, BSI recommends
standard security measures for typical IT systems in its IT-Grundschutz30 [IT baseline
protection]. The aim of these IT-Grundschutz [IT baseline protection] requirements is –
through the suitable application of standard security measures at organizational,
manpower, infrastructure and technical levels – to achieve a security level for IT systems
which is reasonable and sufficient for normal protection requirements and which can serve
as a basis for IT systems and applications with high security requirements.

IT-Grundschutz [IT baseline protection] includes the BSI-Standards31 [BSI standards] for IT
security management and the IT-Grundschutz-Kataloge32 [IT baseline protection
catalogues] which replace the previous IT-Grundschutzhandbuch [IT Baseline Protection
Manual]. The BSI-Standards [BSI standards] are broken down into:

a. BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS)33
[BSI standard 100-1: Management systems for Information Security],

b. BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise34
[BSI standard 100-2: IT baseline protection approach] and

28 Refer, for instance, to section 8.1.4 "Implementation of the security concept" on page 93 and
section 8.5.4 "Technologies for authentication" on page 104
29 Refer to [SIGA]
30 Refer to http://www.it-grundschutz.de/
31 Refer to http://www.bsi.de/literat/bsi_standard/
32 Refer to http://www.bsi.de/gshb/deutsch/
33 Refer to http://www.bsi.bund.de/literat/bsi_standard/standard_1001.pdf
34 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf

SAGA 4.0 15

c. BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz35
[BSI standard 100-3: Risk analysis on the basis of IT baseline protection].

The application of IT-Grundschutz [IT baseline protection] is supported in SAGA; the BSI-
Standards [BSI standards] for IT security management and the IT-Grundschutz-Kataloge [IT
baseline protection catalogues] are defined as mandatory standards36.

Barrierefreie Informationstechnik-Verordnung – BITV [barrier-free information technology
ordinance]
The ordinance on the creation of barrier-free information technology pursuant to section 11
of Behindertengleichstellungsgesetz [law on equal opportunities for the disabled]
(Barrierefreie Informationstechnik-Verordnung – BITV)37, which came into effect on 24 July
2002, is referenced in SAGA and is defined as a mandatory standard with regard to the
implementation of the presentation and client layers38.

V-Modell XT

The V-Modell XT39 is the binding process model throughout the federal administration for
the development of IT systems for the federal authorities. The V-Modell XT must be
considered in strategic planning and project management efforts and in conjunction with
the implementation of eGovernment applications.

Used as a guideline for planning and implementing development projects, this model
defines the results to be achieved in a project whilst considering the entire system lifecycle.
At the same time, it describes the concrete approach with which these results are to be
achieved. Furthermore, the V-Modell XT also defines the responsibilities of each project
participant. It hence serves as a basis for contracts, as a guideline for work and as a basis for
communication.

The V-Modell XT is subject to ongoing upgrading in the form of releases.

IT Infrastructure Library – ITIL
When it comes to the efficient and reliable management of IT processes, the "IT Infrastruc
ture Library" (ITIL), as a process library which supplies best practices, has now become
established as the globally accepted defacto standard. This is why KBSt has issued a series of
publications concerning the application of ITIL40.

In ITIL, Service Management addresses a general-interest topic that must be considered
from the beginning of the lifecycle of an IT application. This results in synergies for the
approach according to the other standards which are presented in a KBSt study41.

35 Refer to http://www.bsi.de/literat/bsi_standard/standard_1003.pdf
36 Refer to chapter 7 on page 79 and section 8.1 on page 91
37 Refer to http://bundesrecht.juris.de/bitv/
38 Refer to sections 4.5.3 on page 47 and 8.6.1 on page 105
39 Refer to http://www.kbst.bund.de/v-modell
40 Refer to http://www.kbst.bund.de/itil
41 Refer to "ITIL und Standards für IT-Prozesse" [ITIL and Standards for IT Processes], version
1.0.1, KBSt Letter No. 1/2006, October 2006

16 SAGA 4.0

During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order to
use a tried-and-tested approach as a basis and to be able to refer to German literature, ITIL
version 2.0, which is supported by KBSt documents, is presented in the Engineering
Viewpoint (chapter 7)42.

Migrationsleitfaden [Migration guide]
This guide43 is designed to offer both strategic/economic and detailed technical decision-
making aids for forthcoming or recently completed migration projects. The focus of this
guide is the replacement of proprietary products both with open source software (OSS) and
– where necessary – future generations of proprietary products. Agency-specific scenarios
are developed and different migration alternatives are discussed.

The Migrationsleitfaden [migration guide] was developed with a view to SAGA version 2.1 as
far as relevant interfaces were concerned. SAGA updates will have no repercussions on the
statements made.

DOMEA-Konzept [DOMEA concept]

DOMEA44 stands for "Dokumentenmanagement und elektronische Archivierung"
[document management and electronic archiving] in IT-based workflows. The aim of this
concept is to introduce the electronic file. Physical files are to be replaced with workflows at
public agencies in the form of fully electronic, media-consistent procedures. The electronic
file is subject to the same legal and functional requirements as conventional files. Since the
publication of the concept in 1999, DOMEA has become an established standard for
electronic workflows at federal, federal-state and municipal agencies. For product
manufacturers, the DOMEA-Konzept [DOMEA concept] is a major source of information
when it comes to identifying the demands of public administrations which are considered
when products are developed further.

Besides the organizational concept and the resultant requirements catalogue, the modular
concept includes further elements which address specific issues of the organizational
concept in more detail.

The requirements catalogue of the DOMEA concept translates organizational requirements
into functional requirements which are orientated towards the SAGA standards on the one
hand whilst also influencing the updating process of the SAGA document on the other. The
DOMEA concept describes the relevant requirements for software products related to the
area of electronic workflow management. These requirements are in some respects even
more demanding than SAGA and hence do not jeopardise SAGA conformity.

42 Refer to section 7.1 "IT Service Management with the ITIL" on page 79
43 Refer to http://www.kbst.bund.de/migrationsleitfaden
44 Refer to http://www.kbst.bund.de/domea

SAGA 4.0 17

1.7 The evolution process
Standards and architectures in SAGA undergo a defined process before they are included:

a. Proposal for standards and architectures in the public discussion forum, via the contact
form, from the SAGA expert group, the KoopA-SAGA project group, the central IT
service providers from the federal administration or the SAGA authors

b. Examination of proposals by the SAGA authors

c. Discussion in the SAGA expert group on the standards and architectures which were
found to be suitable by the SAGA authors

d. Acceptance of proposals in a KBSt resolution on the basis of the discussion between the
SAGA authors and the SAGA expert group

e. Inclusion of the accepted standards and architectures in SAGA by the SAGA authors as
soon as the resolution has been made by the KBSt

SAGA is updated at regular intervals, amended to reflect the latest developments and
findings and published on the homepage of the KBSt45 and within the scope of the E-
Government-Handbuch46 (eGovernment Manual).

If problems occur that cannot be resolved using known standards, requests for proposals
(RFPs) are sent to the SAGA expert group in order to identify possible solutions.

Public discussion forum

A public forum at: http://www.kbst.bund.de/saga-forum enables Internet users to register
and discuss issues related to the application and further development of SAGA. The results
of the discussions are evaluated and, if suitable, are considered in the next version of the
SAGA document.

Contact form
The SAGA homepage provides a contact form47 for SAGA users. This form can be used to
send structured ideas and queries directly to the SAGA authors.

The SAGA expert group

The KBSt has established an expert group48 comprising representatives from business,
science and administration and appoints the members. This expert group is involved in the
updating process at regular intervals or whenever there is reason for involvement.

The KoopA-SAGA project group and central IT service providers of the federal administration
The Co-operation Committee for Automatic Data Processing for the Federal-government,
Federal-state Government and Municipal Administration Sector (KoopA ADV) delegates

46 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm
47 Refer to http://www.kbst.bund.de/saga-kontaktformular
48 Refer to http://www.kbst.bund.de/saga-expertenkreis

18 SAGA 4.0

representatives from the federal states and municipalities to accompany the further
development of SAGA in workshops. The SAGA authors draft a catalogue of questions for
proposed amendments which are answered by the participants and supplemented by their
own proposals. In analogy to this approach, the requirements of the central IT service
providers of the federal administration are collected in workshops and written exchanges
and taken into consideration in the updating of the document.

SAGA examination report
The proposals put to the SAGA authors in the public forum, via the contact form, in the
SAGA expert group, in the KoopA-SAGA project group and by the central IT service
providers of the federal administration are listed in a SAGA examination report49 and the
result of the examination is documented. The reasons for acceptance or rejection are
explained.

1.8 Structure of the document
Chapter 2 addresses issues concerning the scope of validity and binding nature of SAGA.
Furthermore, this chapter also presents minimum requirements concerning the openness
of standards as well as definitions of the different classification of standards. In addition to
this, the subject of SAGA compliance of eGovernment applications is dealt with.

Chapter 3 describes the architecture model for eGovernment applications. This model was
also adopted for the description of eGovernment in Germany. Accordingly, the following
chapters 4 to 8 present viewpoints of the architecture model on eGovernment in its totality.

a. Chapter 4 documents the goals of German eGovernment, the players, roles, frames of
reference, guidelines and forms of interaction as well as the aims with regard to
standardized processes (enterprise viewpoint).

b. Chapter 5 describes the activities for defining standardized data models and help for
developers of data models (information viewpoint).

c. Chapter 6 contains a reference software architecture, which can be used to develop
architectures for concrete eGovernment applications, and information for integrating
modules, such as the one-for-all offerings (OFA offerings), into the software architecture
(computational viewpoint).

d. Chapter 7 describes the IT Service Management and requirement of eGovernment
computer centres for operating eGovernment applications, as well as the use of
modules, such as OFA offers, in an existing infrastructure (engineering viewpoint).

e. Chapter 8 defines the standards, technologies and methods for the IT architecture and
for ensuring data security (technology viewpoint).

Appendix A contains a list of references and Appendix B provides an alphabetic list of the
standards referred to in chapter 8. Appendix C finally presents a list of the abbreviations
used in SAGA.


SAGA 4.0 19

2 Fundamentals of SAGA
2.1 Scope of validity and binding effect of
SAGA
Around 400 services have so far been identified for the different federal administrations.
The services can be classified, for instance, according to their target groups50; refer to Fig. 2-
1.

G2C – Government to Citizen G2B – Government to Business G2G – Government to Government
(Interaction between the (Interaction between the (Interaction between administrations)
administration and citizens) administration and business)

• BA: Job exchange • BA: Job exchange • KBA: Central traffic and motor
• DRV: Calculation and payment of • BeschA: Procurement vehicle register
pensions • BBR: Procurement for • BBR: Procurement for construction
• BMAS: Provision of information construction and civil engineering and civil engineering projects
• DWD: Weather forecast and projects • BMF: Management of Federal-
meteorological advice • BMBF: Project-related subsidies Government properties
• BpB: Provision of information and • BMWi: Subsidy programmes • BAköV: Further training and
order handling education
• BZR: Federal Central Criminal
Register

Figure 2-1: Selected Federal Government services

SAGA's scope of validity covers the federal administration and software systems with
interfaces between federal authorities and federal-state and/or municipal authorities in
order to support the services listed above.

SAGA includes recommendations concerning standards and architectures for
eGovernment applications. The term "eGovernment applications" refers to software
systems which are used to fulfil services of the Federal Government or which actively
support the fulfilment of such services. In the case of systems with no direct interfaces with
eGovernment, migration is recommended on condition of a positive outcome of the cost-
to-benefit analysis. Whenever possible, the standard software51 to be bought should be
primarily products or product versions which are compatible with SAGA recommendations.
Furthermore, SAGA considers only those areas which have a major influence on the
aforementioned objectives52 rather than all the elements of a technical architecture.

The Federal Ministry of the Interior recommends that SAGA be considered in invitations to
tender for eGovernment applications for the federal administration in the manner
described in section 2.4.1 "Definition of conformance" on page 25, and section 2.4.2 "SAGA
conformance in invitations to tender" on page 26.

50 Refer to the section 4.6.2 on "Relationships in interaction" on page 49.
51 Software that is simply installed and configured
52 Refer to section 1.3 "Aims" on page 12.

20 SAGA 4.0

The federal ministries lay down rules for the binding effect of SAGA within their areas of
competence.

2.2 Minimum requirements with regard to
the openness of standards
One aim of SAGA is the use of open standards in eGovernment applications, refer to section
1.3 "Aims" on page 12. There are currently many different definitions for an "open
standard", however, there is no one generally valid definition accepted by all. Various
standardization committees have issued definitions which are essentially the same in terms
of how a standard emerges, its documentation and application. However, opinions do differ
when it comes to the type of standardization organization and the license cost system of a
standard. These issues are rated differently by the various committees (e.g. IDABC, ETSI,
DIN, CEN, ISO). SAGA is not designed as a forum for these discussions, instead it is to remain
a practice-based recommendation. This is why "minimum requirements" were defined for
the openness of standards which will also serve as an evaluation basis for accepting or
rejecting a standard in SAGA.

The minimum requirements for the openness of standards for acceptance in SAGA are
defined as follows:

a. The standard was published and documentation of standard specifications is either free
or at most available against a nominal fee.

b. The intellectual property (for instance, in the form of patents) of a standard or of parts
of a standard must, if possible, be accessible without being contingent upon the
payment of a license fee.

c. The federal administration and the users of its services must be able to use the standard
without restriction.

d. The standard must remain published and freely usable in the future.

2.3 Classification and life cycles of
standards
2.3.1 Classification in SAGA
Standards are divided into three categories. Competing standards which are not stated
should not be used or only if absolutely inevitable; refer also to section 2.3.4 "Non-classified
standards" on page 25.

Under observation:

Standards are under observation if they are in line with the intended development trend,
are finalized and meet the minimum requirements for the openness of standards53. These

53 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on

SAGA 4.0 21

standards may not yet have proven their worth in practical application or do not meet all
the aims of SAGA; refer to section 1.3 "Aims" on page 12.

In the event that no competing mandatory or recommended standards exist in addition to
the standards under observation, such standards under observation can be used in
eGovernment applications. Only in justified exceptional cases should preference be given
to standards under observation over higher classified alternatives.

Recommended:

Standards are recommended if they have been tried and tested in practical application but
if a more suitable, mandatory standard exists or if they do not meet all the aims of SAGA.
However, minimum requirements for the openness of standards must be fulfilled and
investment security warranted.

In the event that no competing mandatory standards exist besides recommended
standards, deviations from the recommended standards are permitted in justified,
exceptional cases only.

Competing standards can be recommended parallel if they have clearly different fields of
application. The standard which is best suited for the given application must be adopted in
such cases.

Mandatory:

Standards are mandatory if they have been tried and tested in practical application and
represent the preferred solution. They are established on the market and meet all the aims
of SAGA. Such standards must be observed and applied with priority.

Competing standards can be mandatory parallel if they have clearly different fields of
application. In such cases, the standard which is best suited for the given application must
be used.

In the event that mandatory and recommended standards or standards under observation
exist parallel, the latter - i.e. standards under observation - should only be adopted in
justified, exceptional cases.

A standard classified as mandatory does not necessarily have to be used in every
eGovernment application. A mandatory standard only should be adhered to if the use of the
technology or functionality related to this standard is necessary or reasonable in view of the
requirements of the specific application.

2.3.2 Extended classification of standards
Three lists for the extended classification of standards were introduced with the publication
of SAGA 2.0 on the SAGA homepage at http://www.kbst.bund.de/saga-standards. No
standards other than those on the Right of Continuance List (former Grey List) may be given
preference over the standards classified in the SAGA document (mandatory, recommended,

page 20.

22 SAGA 4.0

under observation) – however, only if existing systems, in which these standards are already
used, are being upgraded.

List of Suggestions
The List of Suggestions (former White List) was created in order to respond promptly to new
developments and to be able to communicate these externally for information. During the
course of developing the SAGA document further, the List of Suggestions is an important
basis for including standards in SAGA.

Standards are listed in the List of Suggestions if proposals and ideas for their inclusion in
SAGA were submitted to the SAGA authors, if they have potential for use in eGovernment
applications and if these standards have not yet been classified further.

Standards in the List of Suggestions are evaluated by the SAGA authors and the SAGA expert
group. The result of this evaluation can mean acceptance of the standards in the next
version of the SAGA document, relocation to the Negative List (former Black List) or to the
Right of Continuance List (former Grey List) or also remaining on the List of Suggestions, so
that development can be observed, for instance, in the case of standards not yet finalized.
Before being published in a new SAGA version, the standards on the List of Suggestions are
again examined with regard to their suitability for inclusion.

Right of Continuance List

Standards are added to the Right of Continuance List (former Grey List) if they are no longer
included in the current SAGA version, but if they had a "recommended" or "mandatory"
status in an earlier SAGA version and/or if they were widely used in the market in the past.
When existing systems are upgraded, these standards are to be kept in effect and can
continue to be used. These standards, however, should no longer be used for new
eGovernment applications.

Negative List
Within the scope of the SAGA discussion, certain standards that were already rejected in the
past are repeatedly proposed for inclusion. The Negative List (former Black List) was set up
in order to make the results of these discussions transparent and to identify those standards
which can no longer be expected to be included in SAGA.

Standards are added to the Negative List if they were examined and rejected by both the
SAGA authors and the SAGA expert group. The standards should not be used in new or
existing eGovernment applications. Their use is only permitted if a parallel SAGA-
compliant solution exists. Images, for instance, can be made available in BMP format even
though this is on the Negative List, if images are also offered at the same time in a SAGA-
compliant format such as GIF.

If a standard on the Negative List is developed further and differs from the old version in
areas that were previously criticized, the version number of the negative-listed standard
must be stated. Now nothing stands in the way of the new version being included in SAGA
via the List of Suggestions (former White List).

SAGA 4.0 23

2.3.3 Life cycles of standards
Besides the standards classified in SAGA, refer to section 2.3.1 on page 20, other standards
are recorded in three different lists, refer to section 2.3.2 on page 21. Whilst the
classification of standards as "mandatory", "recommended" and "under observation" is
defined and updated in the SAGA document, presentation and ongoing updating of the
standards in the lists are carried out on the SAGA website at:
http://www.kbst.bund.de/saga-standards.

Standards can pass through different stages during their life cycle. These are illustrated in
Fig. 2-2 on page 24.

The transitions of a standard between the lists on the SAGA homepage at:
http://www.kbst.bund.de/saga-standards and the classes in the SAGA document are defined
in the following section.

1 New standards are proposed for classification by the SAGA authors, by experts or by
users; refer to section 1.7 "The evolution process" on page 17. Without any further in-
depth examination, these standards are initially compiled in the List of Suggestions. A
thorough examination is carried out before a new SAGA version is created. Apart from
the transfer to the SAGA document, to the Right of Continuance List or to the Negative
List, the examination may also result in the standard remaining on the List of
Suggestions. Such standards do not yet fulfil the requirements for inclusion in SAGA,
e.g. because they are not yet finalized. Their inclusion is re-examined for the next SAGA
version. Before completion of a new SAGA version, transitions 1 and 2 or 1 and 3 may also
take place in one step.

2 Standards which, following examination, are not included in SAGA are added to the
Negative List as rejected standards.

3 Standards are transferred from the List of Suggestions to the Right of Continuance List
when thorough examination suggests that these standards should not be used in new
projects, but can still be used in existing projects.

4 Following a positive examination of the respective requirements, refer to section 2.3.1
"Classification in SAGA" on page 20, standards are included in SAGA with the
classification "under observation". If the respective requirements are fulfilled, the
standard can also be directly allocated to one of the higher classes, i.e. "recommended"
or "mandatory". The transitions 4 and 5, or 4, 5 and 6, respectively, are then carried out
in one step.

5 Following successful examination of the respective requirements in SAGA, standards
with "under observation" status are classified as "recommended" in SAGA. If the
requirements are fulfilled, the standard can also be directly allocated to the higher
class, i.e. "mandatory". Transitions 5 and 6 are then carried out in a single step.
Standards which after examination still fail to meet the requirements for higher
classification in SAGA and which are not be transferred to the Negative List retain the
"under observation" classification.

24 SAGA 4.0

SAGA DOCUMENT SAGA HOMEPAGE

Mandatory Negative List
(former Black List)

6 7 10 9

8
Recommended Right of Continuance List
(former Grey List)

5 3 2

Under observation 4 List of Suggestions
(former White List)

1

New standards

Figure 2-2: Lifecycles of SAGA standards

6 Following successful examination of the respective requirements in SAGA, standards
with "recommended" status are classified as "mandatory". Standards which after
examination still fail to meet the requirements for higher classification in SAGA and
which are not be transferred to the Right of Continuance List retain the
"recommended" classification.

7 Following examination and the respective re-evaluation in SAGA, standards with
"mandatory" status are classified as "recommended". A standard which should no
longer be used in new projects can also be directly transferred to the Right of
Continuance List. Transitions 7 and 8 are then carried out in a single step. Standards
which, after examination, continue to meet the requirements for classification as
"mandatory" maintain their status.

8 If, after in-depth examination, standards with a "recommended" status should not be
used any longer in new projects, these standards are transferred to the Right of
Continuance List.

9 Obsolete standards in the Right of Continuance List which were kept sufficiently long in
the Right of Continuance and which should not be maintained any longer are
transferred to the Negative List.

10 Standards with "under observation" status which no longer have any chance of ever
being transferred into a higher classification are directly transferred to the Negative
List.

The standards which are examined within the scope of preparing a new SAGA version can
not only move one step along the lifecycle previously presented, they can also retain their
status or pass through several steps in one go.

SAGA 4.0 25

2.3.4 Non-classified standards
Standards or architectures not listed in SAGA:

a. are not specific for eGovernment or eCommerce applications,

b. refer to a detail level other than that of the standards dealt with here in SAGA,

c. are included in or referenced by the aforementioned standards,

d. are too new or too controversial and are hence unlikely to become a standard in the
near future,

e. are not desired because they are in conflict with standards or architectures already
introduced or because they restrict interoperability.

2.4 SAGA conformance
2.4.1 Definition of conformance
The SAGA conformance of an eGovernment application54 is evaluated on the basis of the
models, procedures and standards described in SAGA:

a. Consideration of standardized process models

b. Consideration of standardized data models

c. Compliance with the standards and architectures described in SAGA

d. Use of existing one-for-all offers (OFA offers)55

In order to be able to make a comprehensive statement concerning the SAGA conformance
of an eGovernment application – especially in conjunction with the implementation of
complex, specialized processes – an application should first be broken down into individual
units56 before evaluating its conformance. Software units developed internally are
distinguished here from units (products) developed externally. In order to evaluate the
SAGA conformance of products, importance is primarily attached to communication
interfaces, data interchange formats and security. In the case of in-house developments,
the technologies for creating models and implementing the application are additionally
relevant as is the use of OFA offers.

The SAGA homepage provides a blank declaration of conformance and an example of a
completed declaration of conformance with checklists for software units and external
units57. The checklists feature topical areas which are relevant for in-house developments or
for products, respectively.

54 The term "eGovernment application" is used as a general term for any IT system which
provides eGovernment services of the Federal Government. With regard to the definition of
the term "eGovernment service", please refer to section 4.1.2 "The term "service" in
eGovernment" on page 35.
55 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.
56 According to the XT process model, a unit is the system element on the very top of a
hierarchical structure; refer to http://www.v-modell-xt.de/
57 Refer to http://www.kbst.bund.de/saga-konformitaet

26 SAGA 4.0

eGovernment application

SW unit 1 External unit 1 ... Unit n
(In-house (product) (...)
development)

Check-list for SW Check-list for ... Check-list for
units developed external units ...
in-house (products)

Figure 2-3: Layout of the SAGA declaration of conformity and checklists

Which specific standards from the relevant topical areas have to be used to ensure SAGA
conformance varies depending on the area of application and the functional scope of the
application. For instance, definitions for creating information services for mobile phones
and/or PDAs are only relevant for SAGA conformance if these terminal devices are to be
used by the eGovernment application. SAGA conformance is hence achieved by applying
the particular subset of all SAGA standards which is relevant for the specific eGovernment
application.

2.4.2 SAGA conformance in invitations to tender
In order to avoid neglecting the customer's concrete requirements when it comes to SAGA
conformance and in order to avoid having to exclusively rely on statements by the supplier,
the customer should include a section on "SAGA conformance" and SAGA-relevant criteria
in its contracting documents.

A general demand for SAGA conformance is not enough in order to achieve the goals of
SAGA. Due to the complexity of the document, a general demand leaves too much room for
interpretation and misunderstanding. This makes it difficult for the supplier to fulfil the
requirements and for the customer to check that requirements are fulfilled.

This is why no general demand for SAGA conformance may be made.

Instead, the declaration-of-conformance process described below should be applied by the
customer and the supplier, refer to Fig. 2-4. This process limits the room for interpretation
and reduces misunderstandings. The concrete demands can be checked and thus create a
sound basis for the contract between the customer and the supplier. Specifying the
concrete details of demands also prevents offers from becoming unnecessarily expensive.

SAGA 4.0 27

CUSTOMER SUPPLIER
Project started

Create contracting Send documents
1
documents
with criteria related to SAGA

Send offer Write offer
including replies concerning 2
customer criteria related to SAGA

Evaluate offer Award contract
3 considering supplier replies
concerning SAGA criteria

Hand over application Implement job
and subsequently complete SAGA 4
conformance declaration
Perform acceptance
5 and check
SAGA conformance

Project completed

Figure 2-4: Declaration-of-conformance process

The process essentially comprises five steps which are briefly described below.

Step 1: Including aspects of SAGA conformance aspects in the contract documents of an
invitation to tender

The customer puts together a series of exclusion and evaluation criteria which cover all the
relevant aspects of the desired application. The criteria group example which can be
downloaded from the SAGA homepage can serve as a template58. This criteria group
example contains possible criteria which can result from the application of SAGA. The
customer must select or supplement the criteria which are relevant for the project. The
criteria group example contains explanatory information which makes selection easier.

The customer must also decide whether criteria are defined as exclusion criteria or as
evaluation criteria. Exclusion criteria should be used very moderately because they reduce
the number of bids. Alternatively, high-weighted evaluation criteria should be taken into
consideration.

Step 2: Supplier response to the SAGA conformance criteria group within the scope of offer
preparation
The supplier responds to the "SAGA conformance" criteria group within the scope of his
offer preparation. He can base his offer on a completed criteria group example which can
also be downloaded from the SAGA homepage59. This criteria group is filled in, it serves as


28 SAGA 4.0

an example and contains explanatory comments which are helpful when filling in a
concrete criteria group.

Step 3: Supplier examination of the details concerning SAGA conformance, evaluation of the
respective criteria within the scope of offer evaluation

The customer checks the criteria groups completed for the offers received. Offers which do
not fulfil the customer's requirements for the "SAGA conformance" criteria group, i.e.
which cannot warrant "SAGA conformance", are evaluated accordingly.

Step 4: Supplier completion of the declaration of conformance for the completed application

If the supplier has implemented the eGovernment application, he declares the SAGA
conformance of the application in writing. To do so, he completes the declaration of
conformance for the application and attaches the checklists for the individual units of the
application. Deviations from the commitments made in the completed "SAGA
conformance" criteria group should be discussed with the customer at an early point in
time and the reasons for such deviations must be stated in the declaration of conformance.
The supplier can be supported by the sample declaration of conformance that can be
downloaded from the SAGA homepage60. Blank templates of a declaration of conformance
are also available on this homepage.

Step 5: Examining SAGA conformance on the basis of the offer and the declaration of
conformance by the supplier within the scope of acceptance

During acceptance, the customer can evaluate SAGA conformance on the basis of the "SAGA
conformance" criteria group completed by the supplier in the offer and the declaration of
conformance issued after implementation. This evaluation is as easy as possible thanks to
the specific details of the offer. If the application deviates from the commitments made in
the offer, this is deemed to be a defect which must be considered during acceptance.

2.4.3 SAGA conformance despite low classification
A SAGA-conformant application must not necessarily have been implemented solely with
technologies which were given a "mandatory" classification in SAGA. For various reasons,
the use of standards with a lower classification (or even without a classification in SAGA) is
possible without violating SAGA conformance61.

A lack of alternatives
The use of recommended standards is SAGA conformant if no mandatory alternatives exist.
Standards "under observation" can also be used and are SAGA conformant if no mandatory
or recommended standards are listed in SAGA for the respective application purpose.

61 Refer also to the definitions for classification and lists on the web in section 2.3 on page 20

SAGA 4.0 29

Special functions and application areas
If, for an area of application, SAGA not only contains higher classified standards
("mandatory" or "recommended") but also lists standards with a lower classification
("recommended" or "under observation"), the user must refer to the description of the
standards in order to find out the circumstances under which the lower classified standards
can be given preference. The reasons for this are, first and foremost, when extended
functionality62 is required, or special areas of application63. The use of standards "under
observation" should be particularly well considered because no investment security has
been established for these standards and because it is not warranted that they will remain
in effect. With the next version of SAGA, such standards can already be featured on the
Negative List (former Black List).

Parallel offers

If SAGA-conformant standards are used as depicted above, additional standards and/or
formats can be used which are not listed in SAGA or which have a lower classification in
SAGA. If, for example, spreadsheet data64 is made available in CSV format, the same data can
be additionally made available in other formats, such as Microsoft Excel, without violating
SAGA conformance.

Use of external units (products)
In the case of external units (in contrast to software units developed in-house), the focus is
placed on communication interfaces, data interchange formats and security. Technologies
for process modelling, data modelling, application architecture and the use of OFA offers65
do not form part of the checklists for the SAGA declaration of conformance. In the case of
certain units, customers should check whether the corresponding technologies should be
specified in order to make use, for instance, of existing infrastructures for operating the
unit and to achieve synergies with other eGovernment applications.

Technologies beyond the focus of SAGA

Of course, topics for which SAGA does not make or has not yet made any statements have no
effect on the evaluation of the SAGA conformance of an eGovernment application.

2.4.4 Responsibility for conformance
The public agency responsible for an eGovernment application is also responsible for
ensuring conformance with SAGA. The public agencies are also responsible for examining
ways to migrate special applications.

The federal ministries lay down rules for responsibility within their areas of competence.

62 Refer, for instance, to the descriptions for the different PDF versions in section 8.6.7.1 on
page 109
63 Refer, for instance, to the descriptions of Unicode coding in section 8.6.2 "Character sets" on
page 106
64 Refer to section 8.6.7.4 "Formats for spreadsheets for further processing" on page 112
65 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76

30 SAGA 4.0

Due to the complexity of SAGA, the process of securing SAGA conformance is also complex.
This is why efforts are being made to provide even better support for users in future.
Information on the latest developments in this field can be found on the SAGA homepage66
of the Federal Ministry of the Interior.

2.4.5 Migration for conformance

Transition phase
SAGA is undergoing continuous development and regular updating so that it can be
adapted to meet new requirements. This is why individual eGovernment applications,
which are orientated towards an older SAGA version67 , may temporarily not comply with
the current SAGA version.

Migration plans should be developed for non-conformant applications if the result of the
cost-to-benefit analysis is positive. This may only be the case where major enhancements of
the application are concerned.

Measures to achieve conformance

The following measures are designed to support conformance with SAGA:

a. SAGA is included in project planning processes at an early stage.

b. Conformance with SAGA is specified and checked when projects are approved.

c. Conformance with SAGA can be a mandatory criterion for projects subsidized by public
administrations.

d. SAGA conformance is specified as a mandatory criterion for government contracts.

2.4.6 Non-conformance
eGovernment applications which are, as a whole or in part, non-conformant with SAGA are
subject to the following restrictions:

a. The use of one-for-all offers (OFA offers)68 can be restricted.

b. Advisory and consultancy services by competence centres are limited or even
impossible.

c. Interfaces with such systems may under certain circumstances not be supported.

d. Generally speaking, no subsidies are available from public administrations.

67 Old SAGA versions are available from the SAGA archive at: http://www.kbst.bund.de/saga
68 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.

SAGA 4.0 31

3 Architecture model for
eGovernment applications
3.1 Overview
With the architecture model, SAGA aims at the following:

a. In an effort to facilitate communications, a common understanding of up-to-date IT
architectures, IT technologies and eGovernment structures is to be achieved.

b. IT technologies available for eGovernment applications are to be identified, compared,
evaluated with regard to their relevance, and given a uniform and consistent structure
using this model.

c. The aim is to provide uniform standards that can be used when it comes to
implementing eGovernment projects.

The Reference Model for Open Distributed Processing (RM-ODP69), which was standardized
as ISO/IEC 10746-3:1996, is the approach of choice for describing complex, distributed
eGovernment applications. The discussion on the application is broken down into different
viewpoints in order to reduce the complexity of the overall architecture and this in turn
makes it easier to understand and master an application. The object-orientated paradigm70
is the basis for the RM-ODP. Object orientation promotes clear-cut structures, re-usability
and updating capability of both the models created and the system.

The RM-ODP model defines five viewpoints of a system refer to Fig. 3-1:

a. The enterprise viewpoint specifies the purpose, use area and rules of an application.

b. The information viewpoint describes the structure and semantics of the data to be
processed, i.e. the data model.

c. The computational viewpoint represents the breaking down of an application into
functional elements and their interaction interfaces.

d. The engineering viewpoint represents the distribution of the individual elements of the
system to physical resources and their connections.

e. The technology viewpoint describes the technologies used to implement the system.

The five viewpoints can be used both to describe existing systems and to model new systems
and applications. SAGA suggests, but does not dictate, the use of RM-ODP to describe

69 Reference Model of Open Distributed Processing, refer to [ISO 1996]
70 Refer to [KBSt 2007], section 3.3.1

32 SAGA 4.0

Enterprise
Viewpoint

Purpose, use area
and rules

Information Computational
Viewpoint Viewpoint

Data structure System elements
and semantics eGovernment and interfaces

Hardware and Standards and
infrastructure technologies

Engineering Technology
Viewpoint Viewpoint

Figure 3-1: Viewpoints according to RM-ODP

Furthermore, the SAGA document itself is structured according to the RM-ODP model. The
result are chapters which can each be assigned to a viewpoint; refer to section 1.8 "Structure
of the document" on page 18.

3.2 Enterprise viewpoint
The enterprise viewpoint for eGovernment applications includes two fundamental
elements: the organizational structure of eGovernment in general as well as the
organizational models of the application. This is where the overall environment for the
system and its purpose are described. Furthermore, the requirements for the system,
relevant constraints, executable actions and data processing policies are defined from the
organization's or enterprise's point of view. This exercise includes a definition of the
procedures, their rules, as well as the actors and their roles in the process.

The efficiency of information technology depends heavily on an integrated view. This
means that instead of focusing on information technology, the technical application is
primarily regarded and described as a process.

Services can and should be described in the form of technical process models. This means
looking at all the work steps from start to finish, i.e. from the inquiry by the "customer"

SAGA 4.0 33

(citizen, business, other public agency, etc.) to the rendering of the service. On their first
stage of development, these process models should be left at a relatively abstract level.

New proposals for process definitions should always be checked with a view to

a. Re-usability

b. Simplicity

c. The possibility to be described by existing process definitions.

The KBSt website provides a guideline for process and data modelling71 and supports those
in charge during process modelling. Support is also available from the "Workflow
Management, Processes and Organization" (WMPO CC) competence centre72 at the Federal
Office for Information Technology (BIT).

Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35 describes the
enterprise viewpoint of German eGovernment as a model. In section 8.2 "Process models"
on page 95, SAGA provides the descriptive tools needed for the definition of the enterprise
viewpoint for concrete eGovernment applications.

3.3 Information viewpoint
This viewpoint determines the structure and semantics of the system's information.
Furthermore, the activities (status changes) which can be carried out with the information
objects are also defined along with the restrictions which apply to these activities.

A stringent process definition calls for the use of general data definitions for major data
identities (such as the application) and for the data to be exchanged between processes or
applications.

Data models should always be checked with a view to
a. Re-usability

b. Simplicity

c. The possibility to be described by existing data models

The KBSt website provides a guideline for process and data modelling73 and supports those
in charge during data modelling.

Chapter 5 "Information viewpoint: Standardization of data models" on page 55
corresponds to the information viewpoint of German eGovernment and should be
considered when creating own data models. Section 8.3 "Data models" on page 96 classifies
the technologies to be applied.

71 Refer to http://www.kbst.bund.de/modellierungsleitfaden
72 Refer to http://www.kbst.bund.de/, "E-Government" > "Vorgangsbearbeitung, Prozesse und
Organization"
73 Refer to http://www.kbst.bund.de/modellierungsleitfaden

34 SAGA 4.0

3.4 Computational viewpoint
This viewpoint breaks an application down into logic, functional elements which are
suitable for distribution. The result is objects with interfaces via which they offer their
functionality and/or use the functionalities of other objects.

Interaction takes place in the form of local and remote communication between the
elements. Secure interaction may be required here. The protection aims are described in
section 8.1.2.1 "Protection aims" on page 92.

The applications are also broken down into layers in which each of the individual elements
can be found.

Chapter 6 "Computational viewpoint: Reference software architecture" on page 65
provides a description of a general computational viewpoint of eGovernment applications
which can be used as a basis for creating this viewpoint for a concrete online service.
Furthermore, the chapter also describes the architectures of different cases of eGovernment
applications, such as systems and services. In chapter 8 "Technology viewpoint: Standards
for IT architecture and data security" on page 91, SAGA defines standards and technologies
for implementing the computational viewpoint and for creating secure interaction
between system elements.

3.5 Engineering viewpoint
The engineering viewpoint describes the system support needed to permit the distribution
of objects from the computational viewpoint. This includes system elements for executing
objects, such as computer hardware and communication infrastructures, as well as all kinds
of software platforms for distributed systems.

Chapter 7 "Engineering viewpoint: IT service management and reference infrastructure"
on page 79 gives a general description of the engineering viewpoint for eGovernment
applications of federal agencies. The corresponding viewpoint of a concrete online service
can be derived from this. Chapter 8 "Technology viewpoint: Standards for IT architecture
and data security" on page 91 presents several technologies to be adopted in order to
support network security.

3.6 Technology viewpoint
This viewpoint describes the concrete technologies selected for implementing the system.

In chapter 8 on page 91, SAGA describes the classified standards, technologies and methods
for the IT architecture and data security.

SAGA 4.0 35

4 Enterprise viewpoint:
Fundamentals of eGovernment
In line with the definition of the enterprise viewpoint in chapter 3 "Architecture model for
eGovernment applications", the fundamentals of eGovernment in Germany will be
described in the following as the overall environment for the standardized introduction of

Besides this general approach, the process level in eGovernment will also be addressed in
more detail. The process models are the starting point for deriving inter-agency modules
which are to be integrated into eGovernment applications.

4.1 Definitions of eGovernment in Germany
4.1.1 The term "eGovernment"
eGovernment (electronic Government) is understood to be the use of electronic
information and communication technologies in order to involve customers of
administrations in the activities of government and the public administration74. The aim is
to offer customers of administration services, i.e. citizens, businesses and the
administration itself, electronic access to administration services and information. The
possibilities offered by these technologies are very diverse. They range from the
modernization of administrative processes using electronic workflow management to the
provision of administrative information using public agency portals on the Internet and to
complex transactions and interactive electronic web services for citizens.

Aspects of eDemocracy are not explicitly addressed in this context because the government
is assumed to pursue different approaches towards its roles in relation to citizens and
business. As far as eGovernment is concerned, citizens and business are the clients of
administrations and governments. eDemocracy is based on the concept of the citizen as the
sovereign, representing the basis for the government to exert its power.

4.1.2 The term "service" in eGovernment
Within the scope of eGovernment, the term "service" is understood to be the execution or
result of an activity by a public administration which serves the citizen, business or another
public agency75. A service includes processes, obligations and burdens, such as the
recognition as a conscientious objector, applications for unemployment benefits, or the
granting of an import permit.

74 Refer to BSI: "eGovernment Glossary", version dated 4 January 2006, section 1.1, page 3;
http://www.bsi.bund.de/fachthem/egov/download/6_EGloss.pdf
75 Refer to BSI: "eGovernment Glossary", version dated 4 January 2006, section 1.2, page 4;
http://www.bsi.bund.de/fachthem/egov/download/6_EGloss.pdf

36 SAGA 4.0

4.2 The philosophy underlying
eGovernment
eGovernment opens up new ways for reform and innovation in the pubic administration
using electronic services and processes. This concerns internal relationships within
administrations on the one hand as well as external relations between administrations,
citizens and business on the other76.

4.2.1 Orientation towards the needs of citizens
The Internet and networked computer systems are shaping the future. The growing
penetration of the Internet, especially in private households, is also leading to a growing
demand for electronic services by government. eGovernment is the response to this
demand.

For citizens, contact with administrations sometimes involves long distances and waiting
time. Compared to this, Internet-based communication and transactions can help save
considerable amounts of both time and money. This means that in future many citizens will
frequently be able to handle their administration matters from the comfort of their own
homes. Internet portals simplify access to public information and services.

In order to tailor the service offered by administrations to demand, citizens must remain
free to choose which form of access to the administration they wish to use. Access to the
public administration must continue to be possible, in person, via the Internet and e-mail.
These access channels must be integrated into administrations as early and as far as
possible and processed in a standardized manner so that administration work can be
shaped as efficiently as possible. Moreover, Internet barriers and restrictions posed by the
Internet must be reduced and/or avoided.

4.2.2 eGovernment as a location factor for business
Companies maintain regular contacts with the public administration in many different
fields, e.g. for certification, licensing and approval procedures, as well as procedures
related to the customs and excise and tax administration.

On a global scale, all leading industrialized nations introduced powerful eGovernment
services in recent years. eGovernment is today a location factor. The national and EU plans
for expanding eGovernment services in the years to come are hence fully orientated
towards boosting benefits for citizens and especially for companies, as well as reducing the
cost of administration services. In some federal states, the focus is being placed on the
demand-based expansion of eGovernment services and on increasing the number of users.
The beginning integration of administration and business processes along value chains
makes it possible to reduce bureaucracy costs in the interest of business and government,
e.g. in the field of statistics or the import and export of goods.

76 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter I, module
"Chefsache E-Government – Leitfaden für Behördenleiter" [eGovernment as an executive
task – a guide for heads of public administrations]

SAGA 4.0 37

The availability and quality of electronic administration services is hence a factor not to be
underestimated in the global competition to entice companies to relocate or set up
business. Boundary conditions must be attractive and barriers for companies must be kept
as low as possible.

4.3 Strategic goals
The philosophy addressed in the previous section forms the main objective for the strategic
goals of eGovernment for Europe and Germany. In order to reach these goals, the public
administration must be modernized. A general overview of the programmes, strategies and
measures pursued by the Federal Government here with a focus on human resources,
administration management, organization and eGovernment can be found at
http://www.verwaltung-innovativ.de/. The following section presents the Federal
Government's central programmes and strategies which, in the years to come, will pave the
way for the further development of eGovernment on Federal, federal-state and municipal
level in Germany.

4.3.1 eGovernment 2.0 – A Federal Government
programme
The top priority of the eGovernment 2.0 programme77, which was adopted by the Federal
Cabinet in September 2006, is to make the federal administration fit for a service-orientated
information society. The needs of users of eGovernment applications are to be focused on
more in the future – for instance, users are to be enabled to communicate with public
agencies without the fear of identity fraud or electronic annoyance78. Accordingly, the
federal administration's Internet offering is to be expanded by 2010, both in terms of quality
and quantity. The programme is being coordinated by the Federal Ministry of the Interior in
cooperation with the different federal ministries.

The goals listed are supported by measures in four fields of action:

a. Portfolio
Demand-orientated, quality and quantity-related expansion of the eGovernment
offering by the Federal Government (e.g. Arbeitsagentur-Online [online job agency]79)

b. Process chains
Media-consistent electronic process handling between business and the administration
using integrated process chains, as well as standards for interface and exchange
formats (e.g. secure foodstuff chain80)

77 Refer to http://www.kbst.bund.de/e-government/
78 National Plan for Information Infrastructure Protection (NPSI): Federal Ministry of the
Interior, 2005; http://www.bmi.bund.de/, navigation topics "Themen A-Z" [A-Z topics] >
"Informationsgesellschaft" [Information society] > "Sicherheit in der Informationstechnik"
[Security in information technology] > box: "Links zum Thema" [Links to the topic]
79 Refer to http://www.arbeitsagentur.de/
80 IT FoodTrace research project: http://www.itfoodtrace.de/

38 SAGA 4.0

c. Identification
Launch of electronic identity management using future functions and applications, e.g.
on the electronic ID card (ePA)81 as well as the development of eIdentity strategies

d. Communication
A secure communication infrastructure in the form of portals for citizens, businesses
and administrations (e.g. citizens' portals82)

4.3.2 Deutschland-Online - The joint eGovernment
strategy of the Federal Government, federal-state
governments and municipalities.
The aim of Deutschland-Online (DOL)83 is to create a fully integrated eGovernment
landscape in Germany, so that electronically captured data can be exchanged between the
administrations of the Federal Government, federal states and municipalities in a
consistent manner and across all levels. This strategy is based on the following principles:

a. One For All (OFA)
The individual participants from Federal Government, the federal states and
municipalities develop model solutions which are used by the other participants.

b. Responsibility of lead units
The main responsibility for a DOL project lies in the hands of the proposing public
agency which is also in charge of the creation of a tenable business model and its
implementation.

c. Transparency of standards – competition between products.
Transparent standards and process models are used to define a framework for which
various products can be selected, hence promoting interoperability between different
products.

In order to implement the strategic goals, the heads of federal and federal-state
government adopted the Deutschland-Online action plan in June 2006 with six prioritized
projects and extended this in June 2007 with the IT implementation of the EU services
directive84:

Infrastructure85
The Federal Government, federal states and municipalities currently have different
network infrastructures wich are not connected to each other and hence constitute island
solutions. This means that for a host of public agencies it is not always possible to exchange
data with other agencies in a reliable, simple and secure manner. The establishment of a

81 Refer to http://www.epass.de/
82 Refer to http://www.kbst.bund.de/e-government/, navigation item: "Bürgerportale"
[Citizens' portals]
83 Refer to http://www.deutschland-online.de/
84 Refer to http://www.deutschland-online.de/, navigation item "Strategie" [Strategy] >
download: "Aktionsplan Deutschland-Online vom 14.06.2007.pdf" [Deutschland Online
action plan dated 14 June 2007]
85 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] >
"Priorisierte Vorhaben" [Prioritized projects] > "Infrastruktur" [Infrastructure]

SAGA 4.0 39

communication infrastructure for Germany's public administration is designed to create a
uniform network and hence achieve secure electronic communications between public
agencies on Federal, federal-state and municipal level.

Standardization
The purpose of the DOL "Standardisierung" [Standardization] project is to support and
coordinate the development and provision of technical standards for electronic data
interchange (XÖV standards), so that electronic administration processes can be
implemented in an efficient and uniform manner. For this purpose, the project for
supporting the XÖV projects offers public administrations coordinated and harmonized
measures, such as development methods, standardized data models, tools and technical
infrastructures, along with advisory services and PR work.86

IT implementation of the EU services directive87

The goal of the project is to simplify and accelerate electronic administration processes in
Germany within the scope of the EU services directive88. As of the end of 2009,
entrepreneurs in the European Union are to be able to launch and perform their service
activities via a uniform online contact, irrespective of their nationality or of the member
state in which they are currently located. By mid-2008, a model for the IT implementation
of the directive will be developed and tested as a milestone on the road towards this goal.
Within the scope of this model, the infrastructural requirements at national level are to be
defined, the IT support required for media-consistent process handling is to be described, a
suitable IT architecture developed and technologies proposed with a view to the interfaces
required.

Registration services89
The registration data of 82 million citizens in Germany is currently electronically captured,
registered and managed in a distributed manner at more than 5,000 registration offices
and used in approx. 114 million business transactions every year – for instance to provide
information. As of 1 September 2006, the Federal Government was given the sole legislative
competence of registration services as part of federalism reform. The aim is to create a
Federal Identity Register (BMR) in addition to the municipal register in order to simplify
registration procedures for citizens, to make use of the identity register more efficient and
less expensive for businesses and administration, to improve the quality and up-to-dateness
of the registration data and to make it possible to create nationwide, uniform online
services.

86 For more details, refer to section 5.3 "The Deutschland-Online "Standardization" project" on
page 59 and http://www.deutschland-online.de/, navigation items "Vorhaben" [Projects] >
"Priorisierte Vorhaben" [Prioritized projects] > "Standardisierung" [Standardization]
87 Refer to http://www.deutschland-online.de/, navigation item "Strategie" [Strategy] >
download: "Aktionsplan Deutschland-Online vom 14.06.2007.pdf" [Deutschland Online
action plan dated 14 June 2007]
88 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48
89 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] >
"Priorisierte Vorhaben" [Prioritized projects] > "Meldewesen" [Registration services]

„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии

„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии

Recommandé

Recommandé

Contenu connexe

Similaire à „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии

Similaire à „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии (20)

Plus de Victor Gridnev

Plus de Victor Gridnev (20)

Dernier

Dernier (20)

„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии