SAGAStandards and Architectures for eGovernment ApplicationsVersion 4.0March 2008
2                                            SAGA 4.0Reprint, even in part, subject to approvalThis volume was prepared by...
SAGA 4.0            3SAGAStandards and Architectures for eGovernment ApplicationsVersion 4.0March 2008Published bythe Fede...
4   SAGA 4.0
SAGA 4.0                                          5Word of thanksThe Federal Ministry of the Interior and the SAGA authors...
6                                            SAGA 4.0Introduction:This document presents in concise form widely used stand...
SAGA 4.0                                                                                          7Table of Contents 0    ...
8                                                                       SAGA 4.0        6.3    Reference software architec...
SAGA 4.0                                          90         Status, revision history and          outlook0.1        Amend...
10                                          SAGA 4.0to form chapter 8 "Technology viewpoint: Standards for IT architecture...
SAGA 4.0                                          111        Introduction1.1        BackgroundIn an effort to create a mor...
12                                        SAGA 4.0Application developers should feel free to seek further detailed solutio...
SAGA 4.0                                            131.5        Basic principles for eGovernment           applicationseG...
14                                          SAGA 4.0designed as a reference manual and central information exchange for is...
SAGA 4.0                                              15c. BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundsch...
16                                          SAGA 4.0During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was...
SAGA 4.0                                           171.7        The evolution processStandards and architectures in SAGA u...
18                                          SAGA 4.0representatives from the federal states and municipalities to accompan...
SAGA 4.0                                                          192          Fundamentals of SAGA2.1           Scope of ...
20                                          SAGA 4.0The federal ministries lay down rules for the binding effect of SAGA w...
SAGA 4.0                                            21standards may not yet have proven their worth in practical applicati...
22                                          SAGA 4.0under observation) – however, only if existing systems, in which these...
SAGA 4.0                                             232.3.3      Life cycles of standardsBesides the standards classified...
24                                             SAGA 4.0         SAGA DOCUMENT                                             ...
SAGA 4.0                                       252.3.4       Non-classified standardsStandards or architectures not listed...
26                                                SAGA 4.0                                      eGovernment application   ...
SAGA 4.0                                                     27            CUSTOMER                                       ...
28                                            SAGA 4.0an example and contains explanatory comments which are helpful when ...
SAGA 4.0                                           29Special functions and application areasIf, for an area of application...
30                                          SAGA 4.0Due to the complexity of SAGA, the process of securing SAGA conformanc...
SAGA 4.0                                        313        Architecture model for         eGovernment applications3.1     ...
32                                             SAGA 4.0                                              Enterprise           ...
SAGA 4.0                                            33(citizen, business, other public agency, etc.) to the rendering of t...
34                                           SAGA 4.03.4        Computational viewpointThis viewpoint breaks an applicatio...
SAGA 4.0                                          354        Enterprise viewpoint:         Fundamentals of eGovernmentIn l...
36                                         SAGA 4.04.2        The philosophy underlying           eGovernmenteGovernment o...
SAGA 4.0                                         37The availability and quality of electronic administration services is h...
38                                         SAGA 4.0c. Identification   Launch of electronic identity management using futu...
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
 „SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии
Upcoming SlideShare
Loading in...5
×

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

4,284

Published on

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

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,284
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. SAGAStandards and Architectures for eGovernment ApplicationsVersion 4.0March 2008
  2. 2. 2 SAGA 4.0Reprint, even in part, subject to approvalThis volume was prepared by the Federal Ministry of the Interiorin co-operation with ]init[ AG andFraunhofer-Institut für Software- und Systemtechnik (ISST).Homepage and download of the digital version: http://www.cio.bund.de/sagamail to: IT2@bmi.bund.de
  3. 3. SAGA 4.0 3SAGAStandards and Architectures for eGovernment ApplicationsVersion 4.0March 2008Published bythe Federal Ministry of the Interior
  4. 4. 4 SAGA 4.0
  5. 5. SAGA 4.0 5Word of thanksThe Federal Ministry of the Interior and the SAGA authors would like to thank therepresentatives from the federal states and municipalities in the KoopA-SAGA projectgroup, the representatives from the central IT service providers of the federaladministration along with all the members of the SAGA expert group for their supportduring 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 forumand the SAGA contact form and whose committed comments constituted a valuablecontribution towards updating the document.
  6. 6. 6 SAGA 4.0Introduction:This document presents in concise form widely used standards, processes, and methods ofstate-of-the-art IT development for eGovernment applications. Due to the nature of thissubject, 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 areproducts of certain manufacturers or standardization organizations that are protected atnational and international level.In the interest of a simple structure, copyright and source references of this kind weregenerally omitted. The use of a "name" or abbreviation in this document does notmean that they are free from copyrights or intellectual property rights of thirdparties.Furthermore, neither the editor, the authors nor the experts consulted can accept anyresponsibility for the technical functioning, compatibility or completeness of the standardsdiscussed. This version 4.0 was published in October 2007. Please send any comments,amendments or corrections to: Bundesministerium des Innern, Referat IT2. Thesecomments, amendments or corrections can also be published on the SAGA forum athttp://www.cio.bund.de.Version numbers are stated when they are relevant in the specific context discussed. If noversion numbers of standards are stated, the version which is most stable from a marketpoint 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 isquoted 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/sagawas moved to http://www.cio.bund.de/saga. Therefore some of the links given in thisdocument are no longer valid. For information on SAGA please refer tohttp://www.cio.bund.de/saga.
  7. 7. SAGA 4.0 7Table 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. 8. 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.........................................................................................................................136Appendix A References..........................................................................................................................................139Appendix B Overview of Classified Standards....................................................................................................143Appendix C Abbreviations.....................................................................................................................................153
  9. 9. SAGA 4.0 90 Status, revision history and outlook0.1 Amendments to version 3.0This document is a revised version of SAGA, version 3.0. The following changes have beenmade:In chapter 2 "Fundamentals of SAGA", the names of the lists for the extended classificationof technical standards outside the document (White List, Grey List, Black List) were replacedwith 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 wasalso 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 governments signature projects and initiatives"7 .Chapter 5 "Information viewpoint: Standardization of data models" was revised with a viewto the Deutschland-Online "Standardization"8 project and the topics of XGenerator 2.09 andCore Components10.Chapter 6 "Computational viewpoint: Reference software architecture" now also includessections on architecture decisions11 and information addressing the introduction of serviceoriented 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) [GermanDirectory 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 combined1 Refer to section 2.3.2 "Extended classification of standards" on page 212 Refer to section 4.1 "Definitions of eGovernment in Germany" on page 353 Refer to section 4.3.1 "eGovernment 2.0 – A Federal Government programme" on page 374 Refer to section 4.3.2 "Deutschland-Online - The joint eGovernment strategy of the Federal Government, federal-state governments and municipalities." on page 385 Refer to section "Germany as a member of the European Union" on page 436 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 487 Refer to section "Federal Government initiatives and projects in the field of electronic signatures" on page 468 Refer to section 5.3 "The Deutschland-Online "Standardisierung" [Standardization] project" on page 579 Refer to section 5.4.3 "XGenerator 2.0" on page 6210 Refer to section 5.4.4 "Core components" on page 6311 Refer to section 6.3.1 "Architecture decisions" on page 7212 Refer to section 6.3.2 "Introduction of a service oriented architecture" on page 7313 Refer to section 7.1 "IT Service Management with the ITIL" on page 7914 Refer to section 7.4.1 "Deutsches Verwaltungsdiensteverzeichnis [German Directory of Administrative Services]" on page 88
  10. 10. 10 SAGA 4.0to form chapter 8 "Technology viewpoint: Standards for IT architecture and data security".Moreover, products and implementations were persistently replaced by the underlyingstandards. The previous positive list of supported plug-ins was replaced by a list ofrequirements which plug-ins should fulfil in the federal administrations eGovernmentapplications. The topics of "IP telephony"15 and "Registries"16 were re-introduced and thetopic of "Smartcards"17, which was already addressed in SAGA 3.0, was dealt with in moredetail.SAGA 4.0 no longer features a separate appendix for the one-for-all offers (OFA offers) by thefederal administration. The OFA offers will be soon described and will be updated outside ofSAGA 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 conceptwere 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 classificationof existing standards was changed and standards were moved from the document to theRight of Continuance List (former Grey List20).0.2 Future issuesThe following topics are to be examined and dealt with in more detail in the next version ofSAGA:a. Development and standardization of process and data modelsb. IT service management on the basis of the "IT Infrastructure Library" (ITIL) v3.0c. Long-term archiving of dynamic information from databases and websitesd. Communication per instant messaging and chate. Exchange and visualization of 3D dataBesides the SAGA document, the Federal Ministry of the Interior also provides additionalinformation, links and tools on the web21.15 Refer to section 8.7.4 "IP telephony" on page 12516 Refer to section 8.8.1 "Directory services and registries" on page 13017 Refer to section 8.11.2 "Contactless smartcards" on page 135 and section 8.11.3 "Reader units and interfaces for smartcards" on page 13618 Refer to http://www.kbst.bund.de/efa19 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 7620 With regard to the definition of White List and Grey List, refer to section 2.3.2 on page 2121 Refer to http://www.kbst.bund.de/saga
  11. 11. SAGA 4.0 111 Introduction1.1 BackgroundIn an effort to create a more modern and service-orientated administration, the FederalGovernment is implementing more and more administration processes electronically. Theapplication of eGovernment is making it possible for citizens, business and administrationsto handle matters both faster and more efficiently. Standards are needed in order to enablethese many different applications for the future and accessible for all. This is guaranteed bythe Standards and Architectures for eGovernment Applications (SAGA) guideline.Shortly after the launch of the nation-wide BundOnline Initiative, the Co-ordinating andAdvisory Agency of the Federal Government for Information Technology in the FederalAdministration (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 offermore than 400 online services with Internet capability.On the basis of this success, the SAGA expert group continuously accompanies work on thestandards. In this version 4.0, central IT service providers from the federal administrationwere involved for the first time in updating the guideline. The latest developments andexperience are being added to the document through the discussion in the public SAGAforum. In close co-operation with a KoopA-SAGA project group22, the specific requirementsof the federal states and municipalities are also being included. With this knowledge, theSAGA authors regularly prepare an updated version with the Federal Ministry of the Interiorwhich is in charge of content.A host of completed projects has now been orientated towards the state-of-the-art andinvestment-safe standards and technologies recommended by SAGA. Many federalagencies use SAGA to plan and implement their IT projects, so that they can shape theinteroperability of the various planned and existing applications.Widespread acceptance and especially growing interest among federal states andmunicipalities are proof that SAGA is becoming increasingly important for eGovernment inGermany. In this version 4.0, SAGA once again offers a guideline for the economic andfuture-orientated implementation of IT projects in administrations.1.2 Readers of this documentSAGA is primarily designed for decision-makers in the fields of organization, informationtechnology and eGovernment teams in German administrations. The document is aguideline that serves as an orientation aid when it comes to developing concepts fortechnical 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. 12. 12 SAGA 4.0Application developers should feel free to seek further detailed solutions whenever thestandards and solution proposals presented herein are not sufficient for theimplementation of technical requirements.The Federal Government also sees its initiative as a contribution towards the developmentof eGovernment in Germany. The experience gained within the scope of the initiativeshould help to promote nation-wide, inter-agency eGovernment offers.1.3 AimsSAGA 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 Governmentb. Reusability – re-use of process and data models, systems, services and components in various eGovernment projects in order to generate synergiesc. Openness – Inclusion of open standards in eGovernment applications in order to promote their long-term usability23d. Reduction of costs and risks – Considering investment-safe developments on the market and in the field of standardizatione. Scalability – Ensuring the usability of applications as requirements change in terms of volume and transaction frequency1.4 TasksSAGA pursues a comprehensive standardization approach for Germanys administrations inorder to achieve the following goals.Defining technical Standards and Architectures for eGovernment ApplicationsThe technical standards and architectures cover all the levels and elements relevant foreGovernment. They form the basis for the interoperability and compatibility of theeGovernment applications to be developed.Standardizing processes and data in administrationsIn order to achieve interoperability and compatibility of eGovernment applications, it isnecessary to create a basis for standardizing processes and data in Germanysadministrations. In an effort to support this, systems and services are described on the KBStwebsite 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 2024 OFA offering and networks: http://www.kbst.bund.de/efa
  13. 13. SAGA 4.0 131.5 Basic principles for eGovernment applicationseGovernment applications are designed to fully reach their target groups. This is why itshould be possible to access all the functions irrespective of the users selected platform, theconfiguration of the user systems or the abilities of the users. eGovernment applicationsmust be orientated towards the requirements and needs of the target groups.On the basis of these preconditions, the following basic principles are laid down foreGovernment 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 browsers 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 documentsTrials with standards and architectures for eGovernment have been underway for someyears now in Germany and in other countries26. Experience from these trials andinternational 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 updatesare released. This means that SAGA supersedes contents and information of olderdocuments and that new documents consider the contents and information of the latestSAGA version. A broad-based co-ordination process accompanies any SAGA update in orderto avoid conflicts with valid documents.E-Government-Handbuch [eGovernment manual]In order to promote the Federal Governments eGovernment initiative – such as theBundOnline 2005 Initiative that was completed in 2005 – and to support federal-state andmunicipal agencies, the E-Government-Handbuch27 [eGovernment manual] is preparedunder the leadership of the German Federal Office for Information Security. This manual is25 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. 14. 14 SAGA 4.0designed as a reference manual and central information exchange for issues related toeGovernment.The E-Government-Handbuch [eGovernment manual] is a modular compilation of materialthat covers a broader range of issues and topics than SAGA. As far as identical issues areaddressed, the E-Government-Handbuch [eGovernment manual] does so in a moreconcrete manner. This is why certain modules of the eGovernment manual are referencedfrom within SAGA28. SAGA sets forth guidelines, whilst the E-Government-Handbuch[eGovernment manual] explains the implementation of these guidelines and offerspractical advice.In mid-February 2003, SAGA became part of the E-Government-Handbuch [eGovernmentmanual]. It is the module of the manual with the strongest binding effect. All the othermodules are designed to ensure conformity with SAGA.When examining the focal issue of "IT and IT security", the study titled "Sichere Integrationvon E-Government-Anwendungen(SIGA)"29 [Secure integration of eGovernmentapplications] was drafted. The aim of this study is to adapt the technologies presented inSAGA 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 recommendsstandard security measures for typical IT systems in its IT-Grundschutz30 [IT baselineprotection]. 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 systemswhich is reasonable and sufficient for normal protection requirements and which can serveas a basis for IT systems and applications with high security requirements.IT-Grundschutz [IT baseline protection] includes the BSI-Standards31 [BSI standards] for ITsecurity management and the IT-Grundschutz-Kataloge32 [IT baseline protectioncatalogues] which replace the previous IT-Grundschutzhandbuch [IT Baseline ProtectionManual]. 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] and28 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 10429 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.pdf34 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf
  15. 15. SAGA 4.0 15c. 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 [ITbaseline protection catalogues] are defined as mandatory standards36.Barrierefreie Informationstechnik-Verordnung – BITV [barrier-free information technologyordinance]The ordinance on the creation of barrier-free information technology pursuant to section 11of Behindertengleichstellungsgesetz [law on equal opportunities for the disabled](Barrierefreie Informationstechnik-Verordnung – BITV)37, which came into effect on 24 July2002, is referenced in SAGA and is defined as a mandatory standard with regard to theimplementation of the presentation and client layers38.V-Modell XTThe V-Modell XT39 is the binding process model throughout the federal administration forthe development of IT systems for the federal authorities. The V-Modell XT must beconsidered in strategic planning and project management efforts and in conjunction withthe implementation of eGovernment applications.Used as a guideline for planning and implementing development projects, this modeldefines 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 beachieved. Furthermore, the V-Modell XT also defines the responsibilities of each projectparticipant. It hence serves as a basis for contracts, as a guideline for work and as a basis forcommunication.The V-Modell XT is subject to ongoing upgrading in the form of releases.IT Infrastructure Library – ITILWhen 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 becomeestablished as the globally accepted defacto standard. This is why KBSt has issued a series ofpublications concerning the application of ITIL40.In ITIL, Service Management addresses a general-interest topic that must be consideredfrom the beginning of the lifecycle of an IT application. This results in synergies for theapproach according to the other standards which are presented in a KBSt study41.35 Refer to http://www.bsi.de/literat/bsi_standard/standard_1003.pdf36 Refer to chapter 7 on page 79 and section 8.1 on page 9137 Refer to http://bundesrecht.juris.de/bitv/38 Refer to sections 4.5.3 on page 47 and 8.6.1 on page 10539 Refer to http://www.kbst.bund.de/v-modell40 Refer to http://www.kbst.bund.de/itil41 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. 16. 16 SAGA 4.0During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order touse a tried-and-tested approach as a basis and to be able to refer to German literature, ITILversion 2.0, which is supported by KBSt documents, is presented in the EngineeringViewpoint (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 thisguide is the replacement of proprietary products both with open source software (OSS) and– where necessary – future generations of proprietary products. Agency-specific scenariosare developed and different migration alternatives are discussed.The Migrationsleitfaden [migration guide] was developed with a view to SAGA version 2.1 asfar as relevant interfaces were concerned. SAGA updates will have no repercussions on thestatements made.DOMEA-Konzept [DOMEA concept]DOMEA44 stands for "Dokumentenmanagement und elektronische Archivierung"[document management and electronic archiving] in IT-based workflows. The aim of thisconcept is to introduce the electronic file. Physical files are to be replaced with workflows atpublic agencies in the form of fully electronic, media-consistent procedures. The electronicfile is subject to the same legal and functional requirements as conventional files. Since thepublication of the concept in 1999, DOMEA has become an established standard forelectronic workflows at federal, federal-state and municipal agencies. For productmanufacturers, the DOMEA-Konzept [DOMEA concept] is a major source of informationwhen it comes to identifying the demands of public administrations which are consideredwhen products are developed further.Besides the organizational concept and the resultant requirements catalogue, the modularconcept includes further elements which address specific issues of the organizationalconcept in more detail.The requirements catalogue of the DOMEA concept translates organizational requirementsinto functional requirements which are orientated towards the SAGA standards on the onehand whilst also influencing the updating process of the SAGA document on the other. TheDOMEA concept describes the relevant requirements for software products related to thearea of electronic workflow management. These requirements are in some respects evenmore demanding than SAGA and hence do not jeopardise SAGA conformity.42 Refer to section 7.1 "IT Service Management with the ITIL" on page 7943 Refer to http://www.kbst.bund.de/migrationsleitfaden44 Refer to http://www.kbst.bund.de/domea
  17. 17. SAGA 4.0 171.7 The evolution processStandards 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 authorsb. Examination of proposals by the SAGA authorsc. Discussion in the SAGA expert group on the standards and architectures which were found to be suitable by the SAGA authorsd. Acceptance of proposals in a KBSt resolution on the basis of the discussion between the SAGA authors and the SAGA expert groupe. Inclusion of the accepted standards and architectures in SAGA by the SAGA authors as soon as the resolution has been made by the KBStSAGA is updated at regular intervals, amended to reflect the latest developments andfindings 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 forumA public forum at: http://www.kbst.bund.de/saga-forum enables Internet users to registerand discuss issues related to the application and further development of SAGA. The resultsof the discussions are evaluated and, if suitable, are considered in the next version of theSAGA document.Contact formThe SAGA homepage provides a contact form47 for SAGA users. This form can be used tosend structured ideas and queries directly to the SAGA authors.The SAGA expert groupThe KBSt has established an expert group48 comprising representatives from business,science and administration and appoints the members. This expert group is involved in theupdating process at regular intervals or whenever there is reason for involvement.The KoopA-SAGA project group and central IT service providers of the federal administrationThe Co-operation Committee for Automatic Data Processing for the Federal-government,Federal-state Government and Municipal Administration Sector (KoopA ADV) delegates45 Refer to http://www.kbst.bund.de/saga46 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm47 Refer to http://www.kbst.bund.de/saga-kontaktformular48 Refer to http://www.kbst.bund.de/saga-expertenkreis
  18. 18. 18 SAGA 4.0representatives from the federal states and municipalities to accompany the furtherdevelopment of SAGA in workshops. The SAGA authors draft a catalogue of questions forproposed amendments which are answered by the participants and supplemented by theirown proposals. In analogy to this approach, the requirements of the central IT serviceproviders of the federal administration are collected in workshops and written exchangesand taken into consideration in the updating of the document.SAGA examination reportThe proposals put to the SAGA authors in the public forum, via the contact form, in theSAGA expert group, in the KoopA-SAGA project group and by the central IT serviceproviders of the federal administration are listed in a SAGA examination report49 and theresult of the examination is documented. The reasons for acceptance or rejection areexplained.1.8 Structure of the documentChapter 2 addresses issues concerning the scope of validity and binding nature of SAGA.Furthermore, this chapter also presents minimum requirements concerning the opennessof standards as well as definitions of the different classification of standards. In addition tothis, the subject of SAGA compliance of eGovernment applications is dealt with.Chapter 3 describes the architecture model for eGovernment applications. This model wasalso adopted for the description of eGovernment in Germany. Accordingly, the followingchapters 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 thestandards referred to in chapter 8. Appendix C finally presents a list of the abbreviationsused in SAGA.49 Refer to http://www.kbst.bund.de/saga
  19. 19. SAGA 4.0 192 Fundamentals of SAGA2.1 Scope of validity and binding effect of SAGAAround 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 servicesSAGAs scope of validity covers the federal administration and software systems withinterfaces between federal authorities and federal-state and/or municipal authorities inorder to support the services listed above.SAGA includes recommendations concerning standards and architectures foreGovernment applications. The term "eGovernment applications" refers to softwaresystems which are used to fulfil services of the Federal Government or which activelysupport the fulfilment of such services. In the case of systems with no direct interfaces witheGovernment, migration is recommended on condition of a positive outcome of the cost-to-benefit analysis. Whenever possible, the standard software51 to be bought should beprimarily products or product versions which are compatible with SAGA recommendations.Furthermore, SAGA considers only those areas which have a major influence on theaforementioned objectives52 rather than all the elements of a technical architecture.The Federal Ministry of the Interior recommends that SAGA be considered in invitations totender for eGovernment applications for the federal administration in the mannerdescribed in section 2.4.1 "Definition of conformance" on page 25, and section 2.4.2 "SAGAconformance 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 configured52 Refer to section 1.3 "Aims" on page 12.
  20. 20. 20 SAGA 4.0The federal ministries lay down rules for the binding effect of SAGA within their areas ofcompetence.2.2 Minimum requirements with regard to the openness of standardsOne aim of SAGA is the use of open standards in eGovernment applications, refer to section1.3 "Aims" on page 12. There are currently many different definitions for an "openstandard", however, there is no one generally valid definition accepted by all. Variousstandardization committees have issued definitions which are essentially the same in termsof how a standard emerges, its documentation and application. However, opinions do differwhen it comes to the type of standardization organization and the license cost system of astandard. 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 remaina practice-based recommendation. This is why "minimum requirements" were defined forthe openness of standards which will also serve as an evaluation basis for accepting orrejecting a standard in SAGA.The minimum requirements for the openness of standards for acceptance in SAGA aredefined 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 standards2.3.1 Classification in SAGAStandards are divided into three categories. Competing standards which are not statedshould not be used or only if absolutely inevitable; refer also to section 2.3.4 "Non-classifiedstandards" 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. These53 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on
  21. 21. SAGA 4.0 21standards may not yet have proven their worth in practical application or do not meet allthe 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 tothe standards under observation, such standards under observation can be used ineGovernment applications. Only in justified exceptional cases should preference be givento standards under observation over higher classified alternatives. Recommended:Standards are recommended if they have been tried and tested in practical application butif 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 andinvestment security warranted.In the event that no competing mandatory standards exist besides recommendedstandards, deviations from the recommended standards are permitted in justified,exceptional cases only.Competing standards can be recommended parallel if they have clearly different fields ofapplication. The standard which is best suited for the given application must be adopted insuch cases. Mandatory:Standards are mandatory if they have been tried and tested in practical application andrepresent the preferred solution. They are established on the market and meet all the aimsof SAGA. Such standards must be observed and applied with priority.Competing standards can be mandatory parallel if they have clearly different fields ofapplication. In such cases, the standard which is best suited for the given application mustbe used.In the event that mandatory and recommended standards or standards under observationexist parallel, the latter - i.e. standards under observation - should only be adopted injustified, exceptional cases.A standard classified as mandatory does not necessarily have to be used in everyeGovernment application. A mandatory standard only should be adhered to if the use of thetechnology or functionality related to this standard is necessary or reasonable in view of therequirements of the specific application.2.3.2 Extended classification of standardsThree lists for the extended classification of standards were introduced with the publicationof SAGA 2.0 on the SAGA homepage at http://www.kbst.bund.de/saga-standards. Nostandards other than those on the Right of Continuance List (former Grey List) may be givenpreference over the standards classified in the SAGA document (mandatory, recommended, page 20.
  22. 22. 22 SAGA 4.0under observation) – however, only if existing systems, in which these standards are alreadyused, are being upgraded.List of SuggestionsThe List of Suggestions (former White List) was created in order to respond promptly to newdevelopments and to be able to communicate these externally for information. During thecourse of developing the SAGA document further, the List of Suggestions is an importantbasis for including standards in SAGA.Standards are listed in the List of Suggestions if proposals and ideas for their inclusion inSAGA were submitted to the SAGA authors, if they have potential for use in eGovernmentapplications 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 expertgroup. The result of this evaluation can mean acceptance of the standards in the nextversion of the SAGA document, relocation to the Negative List (former Black List) or to theRight of Continuance List (former Grey List) or also remaining on the List of Suggestions, sothat 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 areagain examined with regard to their suitability for inclusion.Right of Continuance ListStandards are added to the Right of Continuance List (former Grey List) if they are no longerincluded 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 cancontinue to be used. These standards, however, should no longer be used for neweGovernment applications.Negative ListWithin the scope of the SAGA discussion, certain standards that were already rejected in thepast are repeatedly proposed for inclusion. The Negative List (former Black List) was set upin order to make the results of these discussions transparent and to identify those standardswhich 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 theSAGA authors and the SAGA expert group. The standards should not be used in new orexisting eGovernment applications. Their use is only permitted if a parallel SAGA-compliant solution exists. Images, for instance, can be made available in BMP format eventhough 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 inareas that were previously criticized, the version number of the negative-listed standardmust be stated. Now nothing stands in the way of the new version being included in SAGAvia the List of Suggestions (former White List).
  23. 23. SAGA 4.0 232.3.3 Life cycles of standardsBesides the standards classified in SAGA, refer to section 2.3.1 on page 20, other standardsare recorded in three different lists, refer to section 2.3.2 on page 21. Whilst theclassification of standards as "mandatory", "recommended" and "under observation" isdefined and updated in the SAGA document, presentation and ongoing updating of thestandards 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 inFig. 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 definedin 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. 24. 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 standards6 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 cannot only move one step along the lifecycle previously presented, they can also retain theirstatus or pass through several steps in one go.
  25. 25. SAGA 4.0 252.3.4 Non-classified standardsStandards 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 conformance2.4.1 Definition of conformanceThe SAGA conformance of an eGovernment application54 is evaluated on the basis of themodels, procedures and standards described in SAGA:a. Consideration of standardized process modelsb. Consideration of standardized data modelsc. Compliance with the standards and architectures described in SAGAd. Use of existing one-for-all offers (OFA offers)55In order to be able to make a comprehensive statement concerning the SAGA conformanceof an eGovernment application – especially in conjunction with the implementation ofcomplex, specialized processes – an application should first be broken down into individualunits56 before evaluating its conformance. Software units developed internally aredistinguished here from units (products) developed externally. In order to evaluate theSAGA conformance of products, importance is primarily attached to communicationinterfaces, data interchange formats and security. In the case of in-house developments,the technologies for creating models and implementing the application are additionallyrelevant as is the use of OFA offers.The SAGA homepage provides a blank declaration of conformance and an example of acompleted declaration of conformance with checklists for software units and externalunits57. The checklists feature topical areas which are relevant for in-house developments orfor 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. 26. 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 checklistsWhich specific standards from the relevant topical areas have to be used to ensure SAGAconformance varies depending on the area of application and the functional scope of theapplication. For instance, definitions for creating information services for mobile phonesand/or PDAs are only relevant for SAGA conformance if these terminal devices are to beused by the eGovernment application. SAGA conformance is hence achieved by applyingthe particular subset of all SAGA standards which is relevant for the specific eGovernmentapplication.2.4.2 SAGA conformance in invitations to tenderIn order to avoid neglecting the customers concrete requirements when it comes to SAGAconformance 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 criteriain its contracting documents.A general demand for SAGA conformance is not enough in order to achieve the goals ofSAGA. Due to the complexity of the document, a general demand leaves too much room forinterpretation and misunderstanding. This makes it difficult for the supplier to fulfil therequirements 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 thecustomer and the supplier, refer to Fig. 2-4. This process limits the room for interpretationand reduces misunderstandings. The concrete demands can be checked and thus create asound basis for the contract between the customer and the supplier. Specifying theconcrete details of demands also prevents offers from becoming unnecessarily expensive.
  27. 27. 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 processThe process essentially comprises five steps which are briefly described below.Step 1: Including aspects of SAGA conformance aspects in the contract documents of aninvitation to tenderThe customer puts together a series of exclusion and evaluation criteria which cover all therelevant aspects of the desired application. The criteria group example which can bedownloaded from the SAGA homepage can serve as a template58. This criteria groupexample contains possible criteria which can result from the application of SAGA. Thecustomer must select or supplement the criteria which are relevant for the project. Thecriteria group example contains explanatory information which makes selection easier.The customer must also decide whether criteria are defined as exclusion criteria or asevaluation criteria. Exclusion criteria should be used very moderately because they reducethe number of bids. Alternatively, high-weighted evaluation criteria should be taken intoconsideration.Step 2: Supplier response to the SAGA conformance criteria group within the scope of offerpreparationThe supplier responds to the "SAGA conformance" criteria group within the scope of hisoffer preparation. He can base his offer on a completed criteria group example which canalso be downloaded from the SAGA homepage59. This criteria group is filled in, it serves as58 Refer to http://www.kbst.bund.de/saga-konformitaet59 Refer to http://www.kbst.bund.de/saga-konformitaet
  28. 28. 28 SAGA 4.0an example and contains explanatory comments which are helpful when filling in aconcrete criteria group.Step 3: Supplier examination of the details concerning SAGA conformance, evaluation of therespective criteria within the scope of offer evaluationThe customer checks the criteria groups completed for the offers received. Offers which donot fulfil the customers 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 applicationIf the supplier has implemented the eGovernment application, he declares the SAGAconformance of the application in writing. To do so, he completes the declaration ofconformance for the application and attaches the checklists for the individual units of theapplication. Deviations from the commitments made in the completed "SAGAconformance" criteria group should be discussed with the customer at an early point intime 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 bedownloaded from the SAGA homepage60. Blank templates of a declaration of conformanceare also available on this homepage.Step 5: Examining SAGA conformance on the basis of the offer and the declaration ofconformance by the supplier within the scope of acceptanceDuring acceptance, the customer can evaluate SAGA conformance on the basis of the "SAGAconformance" criteria group completed by the supplier in the offer and the declaration ofconformance issued after implementation. This evaluation is as easy as possible thanks tothe specific details of the offer. If the application deviates from the commitments made inthe offer, this is deemed to be a defect which must be considered during acceptance.2.4.3 SAGA conformance despite low classificationA SAGA-conformant application must not necessarily have been implemented solely withtechnologies 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) ispossible without violating SAGA conformance61.A lack of alternativesThe 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 mandatoryor recommended standards are listed in SAGA for the respective application purpose.60 Refer to http://www.kbst.bund.de/saga-konformitaet61 Refer also to the definitions for classification and lists on the web in section 2.3 on page 20
  29. 29. SAGA 4.0 29Special functions and application areasIf, 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 thestandards in order to find out the circumstances under which the lower classified standardscan be given preference. The reasons for this are, first and foremost, when extendedfunctionality62 is required, or special areas of application63. The use of standards "underobservation" should be particularly well considered because no investment security hasbeen established for these standards and because it is not warranted that they will remainin effect. With the next version of SAGA, such standards can already be featured on theNegative List (former Black List).Parallel offersIf SAGA-conformant standards are used as depicted above, additional standards and/orformats can be used which are not listed in SAGA or which have a lower classification inSAGA. If, for example, spreadsheet data64 is made available in CSV format, the same data canbe additionally made available in other formats, such as Microsoft Excel, without violatingSAGA conformance.Use of external units (products)In the case of external units (in contrast to software units developed in-house), the focus isplaced on communication interfaces, data interchange formats and security. Technologiesfor process modelling, data modelling, application architecture and the use of OFA offers65do not form part of the checklists for the SAGA declaration of conformance. In the case ofcertain units, customers should check whether the corresponding technologies should bespecified in order to make use, for instance, of existing infrastructures for operating theunit and to achieve synergies with other eGovernment applications.Technologies beyond the focus of SAGAOf course, topics for which SAGA does not make or has not yet made any statements have noeffect on the evaluation of the SAGA conformance of an eGovernment application.2.4.4 Responsibility for conformanceThe public agency responsible for an eGovernment application is also responsible forensuring conformance with SAGA. The public agencies are also responsible for examiningways 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 10963 Refer, for instance, to the descriptions of Unicode coding in section 8.6.2 "Character sets" on page 10664 Refer to section 8.6.7.4 "Formats for spreadsheets for further processing" on page 11265 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76
  30. 30. 30 SAGA 4.0Due 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 homepage66of the Federal Ministry of the Interior.2.4.5 Migration for conformanceTransition phaseSAGA is undergoing continuous development and regular updating so that it can beadapted to meet new requirements. This is why individual eGovernment applications,which are orientated towards an older SAGA version67 , may temporarily not comply withthe current SAGA version.Migration plans should be developed for non-conformant applications if the result of thecost-to-benefit analysis is positive. This may only be the case where major enhancements ofthe application are concerned.Measures to achieve conformanceThe 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-conformanceeGovernment applications which are, as a whole or in part, non-conformant with SAGA aresubject 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.66 Refer to http://www.kbst.bund.de/saga-konformitaet67 Old SAGA versions are available from the SAGA archive at: http://www.kbst.bund.de/saga68 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.
  31. 31. SAGA 4.0 313 Architecture model for eGovernment applications3.1 OverviewWith 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 standardizedas ISO/IEC 10746-3:1996, is the approach of choice for describing complex, distributedeGovernment applications. The discussion on the application is broken down into differentviewpoints in order to reduce the complexity of the overall architecture and this in turnmakes it easier to understand and master an application. The object-orientated paradigm70is the basis for the RM-ODP. Object orientation promotes clear-cut structures, re-usabilityand 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 systemsand applications. SAGA suggests, but does not dictate, the use of RM-ODP to describeeGovernment applications.69 Reference Model of Open Distributed Processing, refer to [ISO 1996]70 Refer to [KBSt 2007], section 3.3.1
  32. 32. 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-ODPFurthermore, the SAGA document itself is structured according to the RM-ODP model. Theresult are chapters which can each be assigned to a viewpoint; refer to section 1.8 "Structureof the document" on page 18.3.2 Enterprise viewpointThe enterprise viewpoint for eGovernment applications includes two fundamentalelements: the organizational structure of eGovernment in general as well as theorganizational models of the application. This is where the overall environment for thesystem and its purpose are described. Furthermore, the requirements for the system,relevant constraints, executable actions and data processing policies are defined from theorganizations or enterprises point of view. This exercise includes a definition of theprocedures, their rules, as well as the actors and their roles in the process.The efficiency of information technology depends heavily on an integrated view. Thismeans that instead of focusing on information technology, the technical application isprimarily regarded and described as a process.Services can and should be described in the form of technical process models. This meanslooking at all the work steps from start to finish, i.e. from the inquiry by the "customer"
  33. 33. SAGA 4.0 33(citizen, business, other public agency, etc.) to the rendering of the service. On their firststage 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 toa. Re-usabilityb. Simplicityc. The possibility to be described by existing process definitions.The KBSt website provides a guideline for process and data modelling71 and supports thosein charge during process modelling. Support is also available from the "WorkflowManagement, Processes and Organization" (WMPO CC) competence centre72 at the FederalOffice for Information Technology (BIT).Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35 describes theenterprise 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 enterpriseviewpoint for concrete eGovernment applications.3.3 Information viewpointThis viewpoint determines the structure and semantics of the systems information.Furthermore, the activities (status changes) which can be carried out with the informationobjects 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 dataidentities (such as the application) and for the data to be exchanged between processes orapplications.Data models should always be checked with a view toa. Re-usabilityb. Simplicityc. The possibility to be described by existing data modelsThe KBSt website provides a guideline for process and data modelling73 and supports thosein charge during data modelling.Chapter 5 "Information viewpoint: Standardization of data models" on page 55corresponds to the information viewpoint of German eGovernment and should beconsidered when creating own data models. Section 8.3 "Data models" on page 96 classifiesthe technologies to be applied.71 Refer to http://www.kbst.bund.de/modellierungsleitfaden72 Refer to http://www.kbst.bund.de/, "E-Government" > "Vorgangsbearbeitung, Prozesse und Organization"73 Refer to http://www.kbst.bund.de/modellierungsleitfaden
  34. 34. 34 SAGA 4.03.4 Computational viewpointThis viewpoint breaks an application down into logic, functional elements which aresuitable for distribution. The result is objects with interfaces via which they offer theirfunctionality and/or use the functionalities of other objects.Interaction takes place in the form of local and remote communication between theelements. Secure interaction may be required here. The protection aims are described insection 8.1.2.1 "Protection aims" on page 92.The applications are also broken down into layers in which each of the individual elementscan be found.Chapter 6 "Computational viewpoint: Reference software architecture" on page 65provides a description of a general computational viewpoint of eGovernment applicationswhich 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 eGovernmentapplications, such as systems and services. In chapter 8 "Technology viewpoint: Standardsfor IT architecture and data security" on page 91, SAGA defines standards and technologiesfor implementing the computational viewpoint and for creating secure interactionbetween system elements.3.5 Engineering viewpointThe engineering viewpoint describes the system support needed to permit the distributionof objects from the computational viewpoint. This includes system elements for executingobjects, such as computer hardware and communication infrastructures, as well as all kindsof 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 eGovernmentapplications of federal agencies. The corresponding viewpoint of a concrete online servicecan be derived from this. Chapter 8 "Technology viewpoint: Standards for IT architectureand data security" on page 91 presents several technologies to be adopted in order tosupport network security.3.6 Technology viewpointThis viewpoint describes the concrete technologies selected for implementing the system.In chapter 8 on page 91, SAGA describes the classified standards, technologies and methodsfor the IT architecture and data security.
  35. 35. SAGA 4.0 354 Enterprise viewpoint: Fundamentals of eGovernmentIn line with the definition of the enterprise viewpoint in chapter 3 "Architecture model foreGovernment applications", the fundamentals of eGovernment in Germany will bedescribed in the following as the overall environment for the standardized introduction ofeGovernment applications.Besides this general approach, the process level in eGovernment will also be addressed inmore detail. The process models are the starting point for deriving inter-agency moduleswhich are to be integrated into eGovernment applications.4.1 Definitions of eGovernment in Germany4.1.1 The term "eGovernment"eGovernment (electronic Government) is understood to be the use of electronicinformation and communication technologies in order to involve customers ofadministrations in the activities of government and the public administration74. The aim isto offer customers of administration services, i.e. citizens, businesses and theadministration itself, electronic access to administration services and information. Thepossibilities offered by these technologies are very diverse. They range from themodernization of administrative processes using electronic workflow management to theprovision of administrative information using public agency portals on the Internet and tocomplex transactions and interactive electronic web services for citizens.Aspects of eDemocracy are not explicitly addressed in this context because the governmentis assumed to pursue different approaches towards its roles in relation to citizens andbusiness. As far as eGovernment is concerned, citizens and business are the clients ofadministrations and governments. eDemocracy is based on the concept of the citizen as thesovereign, representing the basis for the government to exert its power.4.1.2 The term "service" in eGovernmentWithin the scope of eGovernment, the term "service" is understood to be the execution orresult of an activity by a public administration which serves the citizen, business or anotherpublic agency75. A service includes processes, obligations and burdens, such as therecognition as a conscientious objector, applications for unemployment benefits, or thegranting 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.pdf75 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. 36. 36 SAGA 4.04.2 The philosophy underlying eGovernmenteGovernment opens up new ways for reform and innovation in the pubic administrationusing electronic services and processes. This concerns internal relationships withinadministrations 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 citizensThe Internet and networked computer systems are shaping the future. The growingpenetration of the Internet, especially in private households, is also leading to a growingdemand for electronic services by government. eGovernment is the response to thisdemand.For citizens, contact with administrations sometimes involves long distances and waitingtime. Compared to this, Internet-based communication and transactions can help saveconsiderable amounts of both time and money. This means that in future many citizens willfrequently be able to handle their administration matters from the comfort of their ownhomes. Internet portals simplify access to public information and services.In order to tailor the service offered by administrations to demand, citizens must remainfree to choose which form of access to the administration they wish to use. Access to thepublic 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 aspossible and processed in a standardized manner so that administration work can beshaped as efficiently as possible. Moreover, Internet barriers and restrictions posed by theInternet must be reduced and/or avoided.4.2.2 eGovernment as a location factor for businessCompanies maintain regular contacts with the public administration in many differentfields, e.g. for certification, licensing and approval procedures, as well as proceduresrelated to the customs and excise and tax administration.On a global scale, all leading industrialized nations introduced powerful eGovernmentservices in recent years. eGovernment is today a location factor. The national and EU plansfor expanding eGovernment services in the years to come are hence fully orientatedtowards boosting benefits for citizens and especially for companies, as well as reducing thecost of administration services. In some federal states, the focus is being placed on thedemand-based expansion of eGovernment services and on increasing the number of users.The beginning integration of administration and business processes along value chainsmakes 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]
  37. 37. SAGA 4.0 37The availability and quality of electronic administration services is hence a factor not to beunderestimated in the global competition to entice companies to relocate or set upbusiness. Boundary conditions must be attractive and barriers for companies must be keptas low as possible.4.3 Strategic goalsThe philosophy addressed in the previous section forms the main objective for the strategicgoals of eGovernment for Europe and Germany. In order to reach these goals, the publicadministration must be modernized. A general overview of the programmes, strategies andmeasures pursued by the Federal Government here with a focus on human resources,administration management, organization and eGovernment can be found athttp://www.verwaltung-innovativ.de/. The following section presents the FederalGovernments central programmes and strategies which, in the years to come, will pave theway for the further development of eGovernment on Federal, federal-state and municipallevel in Germany.4.3.1 eGovernment 2.0 – A Federal Government programmeThe top priority of the eGovernment 2.0 programme77, which was adopted by the FederalCabinet in September 2006, is to make the federal administration fit for a service-orientatedinformation society. The needs of users of eGovernment applications are to be focused onmore in the future – for instance, users are to be enabled to communicate with publicagencies without the fear of identity fraud or electronic annoyance78. Accordingly, thefederal administrations Internet offering is to be expanded by 2010, both in terms of qualityand quantity. The programme is being coordinated by the Federal Ministry of the Interior incooperation 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. 38. 38 SAGA 4.0c. 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 strategiesd. 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 eGovernmentlandscape in Germany, so that electronically captured data can be exchanged between theadministrations of the Federal Government, federal states and municipalities in aconsistent 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-stategovernment adopted the Deutschland-Online action plan in June 2006 with six prioritizedprojects and extended this in June 2007 with the IT implementation of the EU servicesdirective84:Infrastructure85The Federal Government, federal states and municipalities currently have differentnetwork infrastructures wich are not connected to each other and hence constitute islandsolutions. This means that for a host of public agencies it is not always possible to exchangedata with other agencies in a reliable, simple and secure manner. The establishment of a81 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]

×