SAGA als Entwicklungs- und Entscheidungshilfe für eGovernment Anwendungen

Was ist SAGA?

Die Spezifikation SAGA wird von der Bundesverwaltung herausgegeben, um Software-Systeme nach einheitlichen Richtlinien zu entwickeln und wurde vom IT-Rat zur verbindlichen Anwendung beschlossen. Ursprünglich stand die Abkürzung für “Standards und Architekturen für eGovernment-Anwendungen”, hat sich mittlerweile aber als Eigenname etabliert. Das Ergebnis ist ein Gemeinschaftswerk aus mehreren hunderten Vorschlägen und Entwürfen, die in einem Abstimmungsprozess aus Beiträgen der Bundesverwaltung, der Ländern, Kommunen, verschiedener nationaler und internationaler Standardisierungsgremien sowie Verbände, Wissenschaft und IT-Industrie zusammengestellt wurden.

![SAGA 5 Logo](http://www.cio.bund.de/SharedDocs/Bilder/DE/Logos/saga_logo_neu.jpg?__blob=normal&v=3)

Wenn Software-Systeme beschafft, erstellt oder weiterentwickelt werden, findet SAGA Anwendung. Die Vorgaben von SAGA gelten für alle neuen Software-Systeme und bei umfassenden Weiterentwicklungen von bestehenden Systemen. Für domänenspezifische Anwendungen können individuelle SAGA-Module erstellt werden, um so auf die Anforderungen der Anwender Rücksicht zu nehmen.

Die enthaltenen Spezifikationen werden in verschiedenen Zustände klassifiziert, die einen festgelegten Lebenszyklus durchlaufen. Spezifikationen können vorgeschlagen, beobachtet, empfohlen, verbindlich, bestandsgeschützt oder verworfen sein. Mit neuen Versionen einzelner Module können die enthaltenen Spezifikationen zwischen den Zuständen wechseln. Die Verbindlichkeit der Vorgabe von enthaltenen Spezifikationen werden durch die Verben muss, sollte, kann und den Verneinungen darf nicht und sollte nicht ausgedrückt.

Für das Klassifikationssystem von SAGA ist der Refegrad eines Standards entscheidend und die Zusammensetzung und das Vorhandensein eines Standardisierungsgremiums. Einige Gremien veröffentlichen eine Vielzahl der verwendeten Spezifikationen in SAGA, z.B. DIN oder ISO.

Wieso ist SAGA sinnvoll?

Die Entwicklungen von Standards und Spezifikationen werden über mehrere Jahre verfolgt.
Diese Nachhaltigkeit soll dauerhafte IT-Lösungen schaffen und einen ausreichenden Investitionsschutz gewährleisten.

Die Ziele von SAGA im Detail sind:

  • Wirtschaftlichkeit: Es gilt sowohl die einmaligen Investitionskosten als auch fortlaufende Betriebs-, Pflege-, Migrations- und Wartungskosten einzuschätzen. Bei der Betrachtung dieser “Total Cost of Ownership” werden Risiken minimiert und damit Investitionssicherheit angestrebt.

  • Agilität: Auf Änderungen der gesetzlichen Anforderungen, wie durch das E-Government Gesetz, müssen Verwaltungen schnell reagieren können. Die Informationssysteme müssen sich auf wechselnde Randbedingungen kurzfristig und flexibel in funktionalen und nicht funktionalen Aspekten anpassen.

  • Offenheit: Es wird Unabhänigkeit von den Interessen einzelner Marktteilnehmer angestrebt. Ein Abhängigkeitsverhältnis kann durch offene, transparente Spezifikationen vermieden werden. Das sichert Nachhaltigkeit, fördert den Wettbewerb und die Verbreitungsgeschwindigkeit von Technologieinnovationen.

  • Sicherheit: Durch die Sensibilität der verarbeitenden Daten in der öffentlichen Verwaltung, besteht ein hoher Schutzbedarf der Vertraulichkeit, Integrität und Verfügbarkeit.

  • Interoperabilität: Um die Auswahl von Software-Systemen nicht einzuschränken, wird eine hohe Interoperabilität benötigt, damit die Kommunikation zwischen Systemen unterschiedlicher Lieferanten ermöglicht wird. Durch Interoperabilität werden Ziele wie Agilität, Offenheit und Wiederverwendbarkeit unterstützt.

  • Wiederverwendbarkeit: Die mehrmalige Verwendung bei ähnlichen Anforderungen, Vermeidung von redundanter Entwicklung sowie Vereinfachung von Betrieb, Pflege und Wartung wird als Wiederverwendbarkeit bezeichnet. So können Lösungen z.B. einfach von einem Landesministerium erprobt und dann bei vielen weiteren eingesetzt werden.

  • Skalierbarkeit: Ein System ist skalierbar, wenn es auf schwankende Intensität bei der Verarbeitung mit geringem Aufwand reagieren kann. Wenn über die Laufzeit einer Lösung mit großen Veränderungen bei der Nutzerzahl, den Transaktionen oder anderen Indikatoren für Leistung zu rechnen ist, sollte ein System möglichst skalierbar sein, um angrenzende Ziele wie Agilität und Wirtschaftlichkeit zu erfüllen.

Welche Spezifikationen sind in SAGA enthalten?

Die folgende MindMap stellt die Kategorisierung im Modul “Technische Spezifikation” in einer Übersicht dar.

Die Kategorien des Moduls 'Technische Spezifikation' von SAGA als MindMap

Alleine diese Kategorisierung hilft dabei, eine umfassende Übersicht über die technischen Problemstellungen bei der Entwicklung einer Applikation für das eGovernment zu gewinnen. Die Hauptkategorien lassen sich wie folgt beschreiben:

  • IT-Sicherheitskonzeption: Der Aufbau und die Einhaltung einer umfassenden Sicherheitskonzeption für die IT werden mit Standards vom Bundesamt für Sicherheit in der Informationstechnik beschrieben. Mit dieser strategischen Grundlage können Maßnahmen geplant und umgesetzt werden, sodass ein sicheres Informationssicherheits-Managementsystem entsteht.
    Beispiele: BSI, IT-Grundschutz-Kataloge

  • Prozessmodelle: Es ist essentiell, dass die IT die Geschäftsprozesse einer Organisation versteht, korrekt umsetzt und sogar Optimierungspotential entdeckt. Für die Spezifikation, Visualisierung und Dokumentation dieser Prozesse werden verschiedene Modellierungswerkzeuge empfohlen.
    Beispiele: EPK, Flussdiagramme, BPMN, UML

  • Datenmodelle: Mit Strukturierung, Schemata von Datenbanken und Semantik werden Daten zu Informationen. Um diese Daten zu modellieren, sodass sie die benötigten Informationen abbilden können, stehen verschiedene Mittel zur Verfügung.
    Beispiele: Entity-Relationship-Diagramme, UML, XSD

  • Applikationsarchitektur: Abhängig von der Größe eines Software-Systems können unterschiedliche Werkzeuge genutzt werden, um eine Softwarearchitektur zu gestalten. Dafür stehen Programmiersprachen und Technologien zur Verfügung. Die Diensteorientierung ist mittlerweile ein üblicher Weg, um Architekturen zu modularisieren und wiederverwendbar zu machen.
    Beispiele: Java SE / EE, PHP, C++, Python, WSDL

  • Client: Ein Client nutzt einen angebotenen Dienst, um ein Endgerät mit Informationen zu versorgen. Der Benutzer interagiert mit dem Client um auf die Informationen zuzugreifen, was von unterschiedlicher Hardware, z.B. Computern oder mobilen Endgeräten erfolgen kann.
    Beispiele: Web-Browser, Java SE, JNLP, E-Mail-Client

  • Präsentation: Clients stellen Daten in unterschiedlichen Formaten dar. Um Informationen möglichst vielen Clients bereitstellen zu können, sollten offene Austauschformate verwendet werden, die die gleichen Inhalte in verschiedenen Formen präsentieren.
    Beispiele: CSS, PDF, HTML, CSV, GIF

  • Kommunikation: Für den Austausch von Informationen zwischen Systemen werden gemeinsame Kommunikationsprotokolle- und kanäle benötigt. Je nach Anwendungsfall sind diese Protokolle für unterschiedliche Aufgaben und Medien geeignet.
    Beispiele: SMTP, FTP, HTTP, SSH, WebDAV

  • Backend: Im Backend werden üblicherweise zentrale Instanzen von Komponenten betrieben, die von vielen Clients erreichbar sein müssen. Dazu zählen z.B. Verzeichnisdienste, Datenbanken und Registrys sowie Legacy-Systeme. Es werden verschiedene Kommunikationsprotokolle verwendet um einen Datenaustausch zwischen diesen Komponenten zu ermöglichen.
    Beispiele: LDAPv3, CMIS, JDBC, JMS, SOAP

  • Verschlüsselung: Um ein optimales Ergebnis aus Sicherheit und Performanz zu erreichen, werden bei der Ver- und Entschlüsselung von Daten typischerweise hybride Kryptosysteme verwendet. Hierbei kommen sowohl symmetrische als auch asymmetrische Verfahren in Kombination zum Einsatz.
    Beispiele: RSA, AES

  • Elektronische Signatur: Mit elektronischen Signaturen kann die Authentizität und Integrität von signierten Daten geprüft und gewährleistet werden. Es werden unterschiedliche Stufen von Signaturen unterschieden, wobei nur die qualifizierte elektronische Signatur eine Rechtsverbindlichkeit sicherstellt. Die zugrunde liegenden Algorithmen bestimmen die Stärke, sodass Signaturen nicht in absehbarer Zeit gebrochen werden können.
    Beispiele: SHA-2, RSA, DSA, XKMS

  • Smartcards: Mit Smartcards lassen sich Daten nicht nur speichern sondern auch verarbeiten, sodass sie als persönliche Sicherheitsumgebung dienen. Sie können private Schlüssel und vertrauenswürdige Zertifikate aufbewahren, womit sie als sichere Einheit zur Signaturerstellung fungieren.
    Beispiele: SICCT, Common PKI

  • Langzeitspeicherung: Aufbewahrungspflichtige Dokumente und Daten werden mit dazugehörigen elektronischen Metadaten langfristig, rechts- und revisionssicher elektronisch gespeichert.
    Beispiele: PDF/A-1, TIFF, XML

SAGA Konformität sicherstellen lohnt sich

Für uns als Produktanbieter und Auftragnehmer im Umfeld von eGovernment bietet sich SAGA sehr gut als Richtlinie an, um unsere Entwicklungen und Beratungsleistungen daran auszurichten. Damit stellen wir für unsere Kunden in der öffentlichen Verwaltung die Homogenität ihrer IT-Landschaft auch mit neuen Lösungen sicher. Es werden keine unnötigen Risiken bei der Technologiewahl eingegangen und man profitiert von den Praxiserfahrungen anderer Anwender.

Auch wenn die letzte Veröffentlichung von SAGA in der Version 5 aus dem Jahr 2011 stammt, ist die Technologiewahl nach unserer Erfahrung in vielen Fällen immer noch aussagekräftig und valid. Die Verwendung von “cutting edge technology” ist nicht immer zielführend und sollte als Risiko einkalkuliert werden. Lediglich die Entwicklungen im Bereich mobiler Endgeräte in den letzten Jahre werden unserer Meinung nach nicht ausreichend abgebildet.

Einen interessanten, modellgetriebenen Ansatz stellt Open SAGA dar. Die Empfehlungen von SAGA wurden in einem Framework umgesetzt, das mit einem Modell befüllt werden kann, um daraus Web-Anwendungen für das e-Government zu generieren. So wird ein guter Mittelweg zwischen Individual- und Standardsoftware gefunden.