konzept für saga 5 - cio.bund.de · steuerung bund“6 zum konzept „it-steuerung bund“ ab....
TRANSCRIPT
2 Konzept für SAGA 5.0
Herausgeber
Der Beauftragte der Bundesregierung für Informationstechnik
Anschrift
Bundesministerium des Innern Alt-Moabit 101 D 10559 Berlin
Bezugsquelle / Ansprechpartner
Stand
Version 1.1 19. Mai 2009 beschlossen vom Rat der IT-Beauftragten am 05.06.2009
Redaktion
Bundesministerium des Innern Referat IT 2 – IT-Steuerung Bund Alt-Moabit 101 D 10559 Berlin
3 Konzept für SAGA 5.0
Inhaltsverzeichnis 1 Einleitung...............................................................................................................................................................................4
2 Ziele von SAGA 5.0...............................................................................................................................................................6
2.1 Wirtschaftlichkeit .........................................................................................................................................................7
2.2 Agilität ..........................................................................................................................................................................7
2.3 Offenheit.......................................................................................................................................................................7
2.4 Sicherheit......................................................................................................................................................................7
2.5 Interoperabilität ............................................................................................................................................................7
2.6 Wiederverwendbarkeit..................................................................................................................................................8
2.7 Skalierbarkeit................................................................................................................................................................8
3 Grundlagen von SAGA 5.0 ....................................................................................................................................................9
3.1 Klassifikationssystem ...................................................................................................................................................9
3.2 Sprachregelungen .......................................................................................................................................................11
3.3 Evaluierungs- und Bewertungsvorgehen ....................................................................................................................11
3.4 Mindestanforderungen an die Offenheit von Standards ..............................................................................................11
3.5 Modularisierung .........................................................................................................................................................11
3.6 Domänenspezifische Varianten...................................................................................................................................12
3.7 Konformität ................................................................................................................................................................12
3.8 Berücksichtigung internationaler Entwicklungen .......................................................................................................13
4 Entstehung und Fortschreibung............................................................................................................................................14
4.1 Projektgruppen des Rates der IT-Beauftragten ...........................................................................................................14
4.2 Allgemeiner Fortschreibungsprozess ..........................................................................................................................14
4.3 Projekt zur Erstellung von SAGA 5.0.........................................................................................................................18
4 Konzept für SAGA 5.0
1 Einleitung SAGA ist ein umfangreiches Dokument, das Standards, Technologien, Architekturen und Methoden
für E-Government-Anwendungen in der Bundesverwaltung qualifiziert, evaluiert und klassifiziert
sowie Empfehlungen für deren Anwendung1 gibt.
Über die Bundesverwaltung hinaus erfreut sich SAGA großer nationaler und internationaler
Beachtung. So findet SAGA auch in der Verwaltung einiger Bundesländer Anwendung, z. B. in
Baden-Württemberg und Brandenburg. Viele Nationen haben bei der Erstellung ihrer nationalen
Interoperabilitäts-Rahmenwerke SAGA analysiert und ggf. adaptiert, wie z. B. Frankreich, Schweiz,
Belgien, Dänemark, Ungarn, Abu Dhabi, Indien und Vietnam.
SAGA wurde bisher von der KBSt erarbeitet und herausgegeben. Durch den „Umsetzungsplan IT-
Steuerung Bund“ in der Version 1.0 vom 20.06.2008 ist jetzt der IT-Rat für SAGA verantwortlich2.
Mit dem Übergang der Verantwortung auf den IT-Rat steigt die Bedeutung von SAGA: Bisher war
die Anwendung von SAGA 4.0 in der Bundesverwaltung lediglich empfohlen und die
Verbindlichkeit wurde durch die Bundesministerien individuell geregelt. Dagegen kann SAGA 5.0
durch Beschluss des IT-Rates nun erstmals für die gesamte Bundesverwaltung verbindlich werden.
Die Verbindlichkeit von SAGA tritt für zukünftige Softwaresysteme sofort, für bestehende
Softwaresysteme bei einer Erweiterung des Funktionsumfanges ein. Hier können bestehende
Softwaresysteme, die deshalb umgestellt werden müssen zeitnah hohe, bisher nicht absehbare
Kosten entstehen. Vor der Aufnahme in SAGA mit Einstufung "verbindlich" muss daher, analog zu
Gesetzesvorhaben, für jeden Standard eine Kostenabschätzung durchgeführt werden.
SAGA entstand ursprünglich im Rahmen der Initiative BundOnline und hat sich bisher nur auf E
Government-Anwendungen bezogen. Mit SAGA 5.0 soll der Blickwinkel auf Softwaresysteme3
erweitert werden, ungeachtet Ihrer Verwendung für das E-Government.
Entsprechend sollte sich auch die Bedeutung des Namens ändern: SAGA ist ein Akronym für
„Standards und Architekturen für E-Government-Anwendungen“. Mit Version 5.0 soll „SAGA“ zum
Eigennamen werden4.
Der Rat der IT-Beauftragten hat ein Grundlagenpapier zur Rahmenarchitektur IT-Steuerung Bund
beschlossen. Die Rahmenarchitektur IT-Steuerung Bund definiert ein Technisches Modells (TM),
das unter anderem anzuwendende Standards umfassen soll. In SAGA 5.0 sollen zunächst nur
Standards für den Bereich Softwaresysteme festlegt werden. In SAGA 5.0 wird also ein Teil des
Technischen Modells (TM) der Rahmenarchitektur IT-Steuerung Bund konkretisieren.
Wie zuvor soll SAGA von der deutschen Bundesverwaltung primär für die eigene Verwendung
entwickelt werden. Die interessierte Öffentlichkeit5 ist eingeladen, die Fortschreibung auch in
1 Die in SAGA 5.0 klassifizierten Standards sollen insbesondere bei der Konzeption und Entwicklung von Softwaresystemen berücksichtigt werden. Bei existierenden Softwaresystemen sind die in SAGA 5.0 klassifizierten Standards dann zu berücksichtigen, wenn der Funktionsumfang erweitert wird.
2 Siehe „Umsetzungsplan IT-Steuerung Bund“, v1.0 vom 20.06.2008, Abschnitt II.6.2, Absatz 3. 3 Der Begriff Softwaresysteme umfasst weder Hardwaresysteme noch eingebettete Systeme. Eine
genaue Definition des Begriffs Softwaresystems ist bei der Erarbeitung von SAGA 5.0 zu erstellen, wobei bereits in vom IT-Rat verabschiedeten Papieren festgelegte Begriffe wiederzuverwenden sind.
4 Analog zur Geschichte des SOAP-Akronyms: Das Akronym SOAP bedeutete anfangs „Simple Object Access Protocol“. Mittlerweile hat sich SOAP weiterentwickelt, dass man es nicht mehr als „simple“ („einfach“) bezeichnen kann. Demzufolge wurde SOAP als Eigenname deklariert.
5 Insbesondere Träger der öffentlichen Verwaltung (Länder, Kommunen etc.), Wirtschaft und Wissenschaft.
5 Konzept für SAGA 5.0
Zukunft aktiv zu begleiten und die Ergebnisse an die eigenen speziellen Anforderungen anzupassen.
Entsprechend soll auch die Version 5.0 von SAGA in die englische Sprache übersetzt werden.
Dieses Konzept erläutert, wie SAGA auf Basis der Version 4.0 weiter entwickelt werden soll, um es
an die neuen Rahmenbedingungen anzupassen und um eine verbindliche Anwendung für die
gesamte Bundesverwaltung zu ermöglichen. Dazu wird auf die Ziele, Inhalte, Grundlagen und die
Prozesse zur Erstellung und Fortschreibung für SAGA 5.0 näher eingegangen.
6 Konzept für SAGA 5.0
2 Ziele von SAGA 5.0 Informationstechnik muss sich als Mittel zum Zweck wohl definierten Zielen unterordnen. Das
Konzept „IT-Steuerung Bund“ des Bundesministeriums der Finanzen und des Bundesministeriums
des Innern stellt dazu im Abschnitt „IT-Steuerung als politische Herausforderung“ fest:
Die IT ist ein wesentlicher Treiber und Faktor für die erfolgreiche Umsetzung politischer
Vorhaben. Die Weiterentwicklung der IT dient auch der Erreichung der strategischen Ziele
der Verwaltungsmodernisierung.
Die IT-Organisation des Bundes ist dringend zu stärken, damit sie bei wachsenden
Herausforderungen und gleichzeitig steigender technologischer Komplexität dauerhaft
wirtschaftliche und qualitativ hochwertige sowie sichere IT-Lösungen bereitstellen kann.
Die Weiterentwicklung von SAGA zur Version 5.0 leitet sich direkt aus dem „Umsetzungsplan IT-
Steuerung Bund“6 zum Konzept „IT-Steuerung Bund“ ab. Anlässlich der in diesem neuen Kontext
postulierten Zielsetzung, der Verantwortung durch den IT-Rat, der geplanten erhöhten
Verbindlichkeit und dem erweiterten Fokus von SAGA 5.0 ist es notwendig, die bisher in SAGA 4.0
postulierten Ziele zu überprüfen und anzupassen bzw. weiter zu differenzieren. In SAGA 5.0 soll es
daher erstmals zwei Kategorien von Zielen geben:
Strategische Ziele für SAGA leiten sich direkt aus der im Konzept „IT-Steuerung Bund“ postulierten
Zielsetzung ab und differenzieren diese. Strategische Ziele sind:
• Wirtschaftlichkeit
• Agilität
• Offenheit
Die beiden letztgenannten Ziele sind Teil einer mittel- und langfristig wirkenden Strategie zur
Erreichung der in der „IT-Steuerung Bund“ geforderten qualitativ hochwertigen IT-Lösungen.
Des Weiteren gibt es technische Ziele für die einzelnen Softwaresysteme der IT-Organisation des
Bundes, die die strategischen Ziele ergänzen:
• Interoperabilität
• Wiederverwendbarkeit
• Skalierbarkeit
• Sicherheit
In den folgenden Abschnitten werden diese Ziele näher erläutert.
Alle Ziele sind gleichberechtigt: Kommt es zu (unvermeidlichen) Interessenkonflikten zwischen
zwei Zielen (z. B. zwischen Wirtschaftlichkeit und Agilität), gibt es keine prinzipielle
Verfahrensweise und der Fall muss individuell betrachtet und entschieden werden.
Aufgrund der kurzen Innovationszyklen in der Informationstechnologie einerseits und den hohen
Investitions- und Migrationskosten für Installationen andererseits müssen alle Ziele von SAGA auf
eine mittel- bis langfristige Perspektive ausgelegt sein, um sie erreichbar zu machen und eine
dauerhafte Wirkung mit ihnen erzielen zu können. Diese Nachhaltigkeit ist eine wesentliche
strategische Vorgabe für alle Ziele: Sie entspricht der Forderung des Konzepts „IT-Steuerung Bund“
6 Siehe „Umsetzungsplan IT-Steuerung Bund“, v1.0 vom 20.06.2008, Abschnitt II.6.2, Absatz 3.
7 Konzept für SAGA 5.0
nach dauerhaften IT-Lösungen und ist gleichzeitig eine notwendige Voraussetzung für einen
ausreichenden Investitionsschutz.
2.1 Wirtschaftlichkeit
Gemäß Bundeshaushaltsordnung (insbesondere §7) sind auch bei der Informationstechnik die
Grundsätze der Wirtschaftlichkeit und Sparsamkeit zu beachten. Bei der Abwägung von Kosten und
Nutzen sind nicht nur die einmaligen Investitionskosten zu betrachten, sondern auch sich
anschließende laufende (Betriebs- und Wartungs-)Kosten. Des Weiteren sind Risiken zu minimieren
und Investitionssicherheit zu gewährleisten.
2.2 Agilität
Die Bundesverwaltung muss Gesetze und Verordnungen jederzeit fristgerecht umsetzen können.
Dafür ist Informationstechnik notwendig, die kurzfristig und flexibel auf wechselnde funktionale
und nicht funktionale Anforderungen reagieren kann.
2.3 Offenheit
Mit diesem Ziel wird angestrebt, dass ein Softwaresystem öffentlich zugänglich ist und dass seine
Weiterentwicklung nicht von den Interessen einzelner Marktteilnehmer abhängig ist.
Standards bilden quasi eine vertragliche Basis für eine lang anhaltende Funktionalität von IT-
Lösungen. Offene Standards machen diese vertragliche Basis transparent für alle Marktteilnehmer,
für die Bundesverwaltung als Kunde einerseits und die Anbieter von IT-Lösungen andererseits.
Damit unterstützen sie das Prinzip der Nachhaltigkeit für die Informationstechnik in der Verwaltung
und fordern zugleich die Innovationskraft der IT-Anbieter.
2.4 Sicherheit
Angesichts der wachsenden Bedeutung von Softwaresystemen und der wachsenden Bedrohungslage
ist die Sicherheit von IT-Lösungen für die Verwaltung von besonderer Bedeutung. Die
Bundesverwaltung verarbeitet Daten, die im Sinne der IT-Grundschutz-Kataloge7 des Bundesamtes
für Sicherheit in der Informationstechnik (BSI) mitunter einen sehr hohen Schutzbedarf bezüglich
der Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit haben. Dies begründet sich allein schon
dadurch, dass ein Missbrauch bestimmter Daten zu Gefahr für Leib und Leben der Bürger und der
nationalen Sicherheit führen kann.
IT-Sicherheit ist eine Querschnittsfunktion, die auf allen Ebenen der Verarbeitung von Daten
Anwendung finden muss. Dazu hat das BSI bereits seit vielen Jahren umfangreiche IT-Grundschutz-
Kataloge entwickelt, die die IT-Sicherheit auf den Ebenen der Infrastruktur, IT-Systeme, Netze und
IT-Lösungen betrachten.
2.5 Interoperabilität
Interoperabilität8 macht den Einsatz von Softwaresystemen unabhängig von ihren Herstellern und
ermöglicht die Vernetzung von Informationen auch jenseits des Horizontes des ursprünglich
geplanten Einsatzbereiches. Als technisches Ziel fördert sie damit die Nachhaltigkeit von IT-
Lösungen und unterstützt zugleich alle strategischen Ziele.
7 Die IT-Grunschutzkataloge stellen keine Vorgehensweise zur Herstellung von IT-Sicherheit dar. Die Erfüllung der Anforderungen der IT-Grunschutzkataloge alleine, kann nicht sicherstellen, dass ein in allen Aspekten der IT-Sicherheit sicheres Softwaresystem entsteht.
8 Analog zum European Interoperability Framework (EIF) 1.0 der EU unterscheidet SAGA zwischen organisatorischer, semantischer und technischer Interoperabilität
8 Konzept für SAGA 5.0
2.6 Wiederverwendbarkeit
Die Wiederverwendbarkeit von Softwaresystemen und IT-Lösungen ermöglicht die schnelle
Anpassung an unterschiedliche Anforderungen, ohne die Softwaresysteme vollständig neu
implementieren zu müssen. Als technisches Ziel unterstützt sie damit direkt die strategischen Ziele
der Wirtschaftlichkeit und Agilität.
2.7 Skalierbarkeit
Skalierbarkeit bedeutet die Fähigkeit eines Software-Systems, sich möglichst kostengünstig einem
stetig wachsenden Bedarf an Verarbeitungskapazität stellen zu können. Je skalierbarer ein Software-
System, desto geringer sind dessen Kosten pro zusätzlichen Benutzer, Transaktion oder anderer
bedeutender Leistungsindikatoren. Damit unterstützt dieses technische Ziel die strategischen Ziele
Wirtschaftlichkeit und Agilität.
9 Konzept für SAGA 5.0
3 Grundlagen von SAGA 5.0
3.1 Klassifikationssystem
SAGA 4.0 kennt folgende (erweiterte) Klassifikationen für Standards9:
• Unter Beobachtung
• Empfohlen
• Obligatorisch
• Vorschlagsliste
• Bestandsschutzliste
• Negativliste
Diese Klassifikationen und der dazugehörige Lebenszyklus10 haben sich im Laufe der Jahre bewährt.
Allerdings kommt es mitunter zu Missverständnissen bzgl. der Bezeichnung der Klassifikation
„Obligatorisch“. Die darin enthaltenen Standards sind nämlich keineswegs verbindlich, sondern eher
als starke Empfehlung zu sehen, was sich allein schon dadurch begründet, dass SAGA 4.0 als
Ganzes nicht in allen Bundesressorts verbindlich ist. Mit einer entsprechenden Begründung ist es
möglich, anstelle eines obligatorischen Standards einen einzusetzen, der „Empfohlen“ ist oder sogar
nur „Unter Beobachtung“.
SAGA 5.0 soll für die gesamte Bundesverwaltung verbindlich werden. Damit muss das
Klassifikationssystem für Standards überdacht werden. Aus den vorgenannten Gründen ergibt sich
an exakt einer Stelle Änderungsbedarf: Die Klassifikation „Obligatorisch“ soll aufgelöst werden.
Alle darin enthaltenen Standards fallen dann initial in die schwächere Klassifikation „Empfohlen“
zurück und entsprechen damit wieder dem eigentlichen Sinn dieser Klassifikation gemäß SAGA 4.0.
Neu eingeführt wird die Klassifikation „Verbindlich“. Abweichungen von solchen Festlegungen
wären nicht zulässig. Der IT-Rat würde initial eine ausgewählte Menge von Standards in diese
Kategorie aufnehmen, um deren Unverzichtbarkeit für moderne Softwaresysteme zu unterstreichen.
Damit ergeben sich folgende überarbeitete Klassifikationen:
SAGA 4.0 SAGA 5.011 Bedeutung12
Unter Beobachtung
Beobachtet Unverändert - siehe SAGA 4.0, Abschnitt 2.3.1 „Klassifizierung in SAGA“.
Empfohlen Empfohlen Wie bisher (siehe SAGA 4.0, Abschnitt 2.3.1 „Klassifizierung in SAGA“), jedoch mit der folgenden zusätzlichen Anforderung zur Konformität eines Software-Systems: Für den Fall, dass bei einer Neueinführung oder funktionalen Änderung oder Erweiterung eines Software-Systems mindestens ein Standard dieser Klassifikation existiert, der nicht angewendet werden soll, sollte eine Wirtschaftlichkeitsbetrachtung erstellt werden, die die Motivation und die Konsequenzen dieser Entscheidung erläutert. Davonausgenommen sind Änderungen, die allein zum Zweck der
9 Siehe SAGA 4.0, Abschnitte 2.3.1 und 2.3.2 auf Seite 20 10 Siehe SAGA 4.0, Abschnitt 2.3.3 auf Seite 23 11 Zwecks einheitlicher Verwendbarkeit werden die Namen aller Klassifikationen zu Adjektiven. 12 Diese Texte dienen lediglich zur Erläuterung und sind keine exakte Definition der jeweiligen
Klassifikation! Die exakten Definitionen erfolgen erst für die Module von SAGA 5.0.
10 Konzept für SAGA 5.0
Wartung oder Fehlerbehebung durchgeführt werden.
Obligatorisch - Entfällt: Alle bisher als „Obligatorisch“ klassifizierten Standards erhalten zur Vorbereitung von SAGA 5.0 initial die Klassifikation „Empfohlen“. Nach weiterer Evaluierung können sie durch das Votum des IT-Rates ggf. als „Verbindlich“ eingestuft werden.
- Verbindlich Neu: Standards können verbindlich werden, wenn sie am Markt etabliert sind, sich in der Praxis bewährt haben und die bevorzugte Lösung darstellen. Standards dieser Klassifikation sind im eigentlichen Sinne des Wortes verbindlich, müssen also bei der Einführung eines neuen Software-Systems für die IT-Organisation des Bundes verwendet werden. Abweichungen gefährden die Ziele von SAGA in hohem Maße und sind deshalb nicht zugelassen. Für den Fall, dass bei einer funktionalen Änderung oder Erweiterung eines bestehenden Software-Systems mindestens ein Standard dieser Klassifikation existiert, der nicht angewendet werden soll, muss eine Wirtschaftlichkeitsbetrachtung erstellt werden, die die Motivation und die Konsequenzen dieser Entscheidung erläutert. Davonausgenommen sind Änderungen, die allein zum Zweck der Wartung oder Fehlerbehebung durchgeführt werden.
Vorschlagsliste Vorgeschlagen Unverändert - siehe SAGA 4.0, Abschnitt 2.3.2 „Erweiterte Klassifizierung von Standards“.
Bestandsschutzliste
Veraltet Unverändert - siehe SAGA 4.0, Abschnitt 2.3.2 „Erweiterte Klassifizierung von Standards“.
Negativliste Verworfen Unverändert - siehe SAGA 4.0, Abschnitt 2.3.2 „Erweiterte Klassifizierung von Standards“.
Tabelle 1: Klassifikationen in SAGA 4.0 und SAGA 5.0
Der Lebenszyklus der Standards bleibt im Vergleich zu SAGA 4.0 nahezu unberührt. Die
Darstellung erfolgt nun lediglich als Zustandsdiagramm gemäß UML 2.0:
Verbindlich (neu)
Empfohlen
Beobachtet
Verworfen (Negativliste)
Veraltet (Bestandsschutzliste)
Vorgeschlagen (Vorschlagsliste)
evaluieren
Klassifikation eines Standards
Abbildung 1: Lebenszyklus von Standards
Ein Standard kann auch mehrere Zustände in einem Schritt durchlaufen. So kann ein Standard von
einer SAGA-Version zur nächsten z. B. von „Vorgeschlagen“ über „Beobachtet“ und „Empfohlen“
11 Konzept für SAGA 5.0
schließlich „Verbindlich“ werden. Lediglich der Zustand „Veraltet“ kann nicht übersprungen werden,
da diesen Standards Bestandsschutz gewährt werden soll.
Die Konsequenzen des neuen Klassifikationsschemas werden im Rahmen der Erstellung von SAGA
5.0 analysiert werden und bei der Anwendung des neuen Schemas entsprechend berücksichtigt.
Dabei werden insbesondere die Auswirkungen auf den Lebenszyklus von Standards und der darauf
basierenden Softwaresysteme betrachtet werden.
3.2 Sprachregelungen
In SAGA 5.0 wird es in Bezug auf die Klassifikation von Standards eine einheitliche Sprachregelung
für muss, sollte, darf sowie die Verneinungen darf nicht und sollte nicht geben:
• muss: Kennzeichnet eine Aussage mit dem Charakter einer verbindlichen Festlegung.
• sollte: Kennzeichnet eine Aussage mit dem Charakter einer positiven Empfehlung.
• darf: Kennzeichnet eine Aussage mit dem Charakter einer gestatteten Option.
• darf nicht: Kennzeichnet eine Aussage mit dem Charakter eines verbindlichen Verbotes.
• sollte nicht: Kennzeichnet eine Aussage mit dem Charakter einer negativen Empfehlung.
3.3 Evaluierungs- und Bewertungsvorgehen
Mit SAGA 5.0 soll das Vorgehen zur Evaluierung und der daran anschließenden Bewertung von
Standards transparenter als bisher dargestellt werden. Angesichts der Fülle von unterschiedlichen
Themengebieten und Aufgaben der Standards ist es allerdings nicht möglich, einheitlich messbare
Kriterien zu formulieren, die man mittels einer Gewichtung zu einer vergleichbaren
Gesamtbewertung kumulieren könnte. Stattdessen sollen Mindestanforderungen und
Ausschlusskriterien stärker herausgestellt werden.
Die Evaluation, ob bestimmte Kriterien von einem Standard erfüllt werden, kann als sachliches
Analyseergebnis dargestellt werden. Für SAGA wird festgelegt, welche Auswirkungen die
verschiedenen Kriterien haben. Beispielsweise kann festgelegt werden, dass eine Anforderung an die
Marktpräsenz eines Standards (z. B. mindestens zwei Implementationen verschiedener Hersteller)
eine notwendige Bedingung für die Klassifikation „Empfohlen“ ist. Aufgrund sachlicher Analyse
kann transparent dargestellt werden, welche Standards diese Anforderung erfüllen.
Außerhalb der Bundesverwaltung könnten beispielsweise bestimmte Länder und Kommunen für sich
festlegen, dass eine Anforderung bereits für die Klassifikation „Beobachtet“ oder erst für die
Klassifikation „Verbindlich“ eine notwendige Voraussetzung ist.
3.4 Mindestanforderungen an die Offenheit von Standards
Derzeit existiert in der Öffentlichkeit eine Vielzahl unterschiedlicher, teilweise inkompatibler
Definitionen des Begriffs „Offener Standard“. In SAGA 4.0 wird daher darauf verzichtet, eine
Definition dieses Begriffs vorzunehmen. Es werden dagegen lediglich Mindestanforderungen an die
Offenheit von Standards gestellt. Ein Standard, der diese Hürde nimmt, kann in SAGA klassifiziert
werden, ist dadurch aber nicht notwendigerweise ein offener Standard im Sinne irgendeiner in der
Öffentlichkeit etablierten Definition13.
Es wird die weitere Entwicklung abgewartet, bevor ggf. eine Definition in SAGA erfolgt.
13 Mit anderen Worten: Die alleinige Klassifikation eines Standards in SAGA macht ihn noch nicht zu einem offenen Standard.
12 Konzept für SAGA 5.0
Für SAGA 5.0 soll diese Vorgehensweise beibehalten werden.
3.5 Modularisierung
Von SAGA 4.0 werden in verschiedenen Kapiteln die folgenden Themen beleuchtet:
• Technische Standards (Präsentation, Kommunikation, Middleware-Technologien etc.) –
Kapitel 8
• Semantische Standards (DOL-Standardisierung, XÖV, XRepository etc.) – Kapitel 5
• Architekturen (Gesamtarchitektur, Referenzarchitektur etc.) – Kapitel 3 und 6
• Organisatorische Standards (V-Modell, WiBe, DOMEA, ITIL, Gesamtinfrastruktur,
Referenz-Infrastruktur, Betrieb) – Kapitel 7 und Einleitung
• Juristische, politische und europäische Rahmenbedingungen, Herausforderungen und
Strategien – Kapitel 4
Um bei der Bearbeitung dieser komplexen Themenfelder einen kürzeren Entwicklungszyklus zu
ermöglichen, ohne gleichzeitig die erforderliche Qualität zu gefährden, soll SAGA 5.0 in Module
aufgeteilt werden, die zeitlich und auch weitgehend inhaltlich unabhängig voneinander publiziert
werden können.
In einem ersten Schritt soll ein Modul erstellt werden, das als ein Teil des Technischen Modells
(TM) der Rahmenarchitektur IT-Steuerung Bund technische Standards für Softwaresysteme festlegt.
3.6 Domänenspezifische Varianten
Die als verbindlich klassifizierten Festlegungen von SAGA 5.0 müssten von allen Ressorts des
Bundes umgesetzt w erden14, um die Ziele von SAGA erreichen zu können.
Aber die verschiedenen Behörden der Bundesverwaltung haben unterschiedliche Anforderungen an
die Ausgestaltung ihrer IT-Organisation15.Deshalb sind domänenspezifische Konkretisierungen der
Empfehlungen von SAGA 5.0 geplant, die
• Empfehlungen weglassen,
• Empfehlungen verbindlich machen,
• Empfehlungen und verbindliche Festlegungen ergänzen.
Abschwächungen verbindlicher Festlegungen wären nicht möglich.
Mit diesem Vorgehen könnte eine Behörde oder sonstiger Anwender eine individualisierte Variante
von SAGA erstellen, die seinen Anforderungen genügt.
Die Form der Publikation von SAGA 5.0 soll die Erstellung von domänenspezifischen Varianten
unterstützen.
3.7 Konformität
Bezüglich der Prüfung bzw. Erklärung der Konformität von Softwaresystemen zu SAGA soll sich in
Version 5.0 zu den Vorgängerversionen nichts ändern16. Das heißt, dass vom Auftraggeber anhand
14 Aufgrund der besonderen Erfordernisse an die Informationstechnik im Verteidigungsressort kann das BMVg von den Festlegungen des Konzeptes für SAGA 5.0 abweichen.
15 Der Bundeswehr sind durch die NATO bindende Standards unter anderem mit den NATO Interoperability Standards Profiles, NISP v3 vorgegeben. Eine Umsetzung dieser Vorgaben erfolgt mit der Technischen Architektur der Bundeswehr, die im genannten Sinne als eine auf die Bedürfnisse des BMVg zugeschnittene Variante von SAGA angesehen werden kann.
13 Konzept für SAGA 5.0
von SAGA die vom konkreten Softwaresystem zu erfüllenden Anforderungen festgelegt werden. Der
Auftragnehmer macht die Zusicherung der Erfüllung dieser Anforderungen zum Bestandteil seines
Angebotes. Nach der Realisierung erstellt der Auftragnehmer eine SAGA-Konformitätserklärung.
Diese wird zusammen mit dem ursprünglichen Angebot vom Auftraggeber geprüft. Eine erfolgreiche
Prüfung ist Voraussetzung für die Abnahme des Softwaresystems.
Bei der Beurteilung der SAGA-Konformität von Software-Einheiten soll auch weiterhin zwischen
eigenentwickelten und externen Einheiten unterschieden werden. Bei externen Einheiten wird vor
allem Wert auf Kommunikationsschnittstellen, Datenaustauschformate und Sicherheit gelegt. Für
Eigenentwicklungen sind zusätzlich die Technologien und Methoden zur Modellierung und
Implementierung des Softwaresystems sowie der Einsatz von EfA-Angeboten (Einer-für-Alle-
Angeboten) relevant.
Bezüglich der Zertifizierung der SAGA-Konformität von Softwaresystemen wird nach wie vor das
Verhältnis von Aufwand und Nutzen als nicht wirtschaftlich eingeschätzt. Stattdessen wird weiterhin
auf SAGA-Schulungen für Projektverantwortliche gesetzt. Für Personen sind SAGA-
Zertifizierungen vorstellbar. Der Nachweis, dass die Projektverantwortlichen die korrekte
Anwendung von SAGA beherrschen, stellt projektbegleitend die Konformität zu SAGA sicher.
Damit wird zum einen verhindert, dass erst zum Projektende Abweichungen entdeckt werden, und
zum anderen, dass einfach pauschal SAGA-Konformität gefordert wird.
Eine pauschale Forderung nach SAGA-Konformität trägt nicht zur Erreichung der Ziele von SAGA
bei. Die pauschale Forderung lässt aufgrund der Komplexität des Dokuments immer Spielraum für
Interpretationen und Missverständnisse. Dies erschwert es dem Auftragnehmer, die Anforderungen
zu erfüllen, und dem Auftraggeber, die Erfüllung der Anforderungen zu kontrollieren.
3.8 Berücksichtigung internationaler Entwicklungen
Bei der Weiterentwicklung von SAGA werden im Rahmen von Kooperationen aktuelle
Entwicklungen bei internationalen Partnern beobachtet und die Anwendung der Ergebnisse nach
dem Ermessen des IT-Rates bzw. des BfIT zeitnah koordiniert. Das Ziel dieser Koordination ist, die
breite Anwendung von SAGA durch Konvergenz bzw. Harmonisierung mit internationalen
Entwicklungen zu erleichtern.
So wird z. B. die Fortschreibung des European Interoperability Frameworks (EIF) vom Programm
IDABC der Europäischen Kommission und die ebenfalls beim IDABC angesiedelte Initiative
CAMSS (Common Assessment Method for Standards and Specifications) vom BfIT aktiv begleitet.
Die Einhaltung verbindlicher internationaler Vorgaben, die sich z. B. aus Bündnisverpflichtungen
Deutschlands ergeben, kann durch SAGA nicht abgeschwächt werden. Ein Beispiel dafür ist das
NATO Architecture Frameworks (NAF). Bei der Entwicklung von SAGA wird auch hier – soweit
mit den Zielen von SAGA vereinbar – eine Konvergenz angestrebt. Möglichst viele Vorgaben von
SAGA sollten mit den internationalen Verpflichtungen vereinbar sein.
Kommt es bei der Koordination zu Interessenskonflikten oder Widersprüchen, werden diese
individuell betrachtet und entsprechend den Zielen und der primären Zielgruppe von SAGA
priorisiert und entschieden.
16 Siehe SAGA 4.0, Abschnitt 2.4 „SAGA-Konformität“ auf Seite 25
14 Konzept für SAGA 5.0
4 Entstehung und Fortschreibung
4.1 Projektgruppen des Rates der IT-Beauftragten
Die vom Rat der IT-Beauftragten eingerichteten Projektgruppen verfolgen gemeinsam das Ziel, das
Konzept IT-Steuerung Bund umzusetzen. Dies ist nur möglich, wenn die Projektgruppen sich
koordinieren, kooperieren, ihre Arbeitsergebnisse untereinander abstimmen und dafür sorgen, dass
ein konsistentes Gesamtergebnis entsteht.
4.2 Allgemeiner Fortschreibungsprozess
Die Entwicklung der Version 5.0 von SAGA wird Teil eines kontinuierlichen
Fortschreibungsprozesses, der in stark vereinfachter Darstellung einem Plan-Do-Check-Act-Zyklus
(PDCA-Zyklus17) entspricht.
Abbildung 2: Fortschreibungszyklus von SAGA
Je nachdem, ob eine neue Hauptversion (regelmäßige vollständige Aktualisierung) oder eine
Zwischenversion (außerordentliche teilweise Aktualisierung) von SAGA entwickelt werden soll, teilt
sich der PDCA-Zyklus bei näherer Betrachtung in zwei verschiedene Prozesse. Die folgende
Abbildung zeigt, wie ein Änderungs-Management die Anforderungen für die nächste Hauptversion
sammelt und ggf. die Erstellung einer Zwischenversion anstößt.
17 Der PDCA-Zyklus wird nach seinem Erfinder auch Deming-Kreis genannt und hat seinen Ursprung im Qualitätsmanagement. Als solcher findet er auch Verwendung in der ISO 9.001 und der ISO 27.001 auf Basis von IT-Grundschutz.
15 Konzept für SAGA 5.0
Abbildung 3: Änderungs-Management für SAGA
Hierbei wurden die unterschiedlichen Rollen nach dem Vorbild des V-Modells XT benannt und
sollen wie folgt besetzt werden:
Rolle Besetzung
Änderungsverantwortlicher (Change Manager) Der Beauftragte der Bundesregierung für Informationstechnik (BfIT) vertreten durch das Referat IT 2 des BMI
Änderungssteuerungsgruppe (Change Control Board)
Der Rat der IT-Beauftragten der Ressorts (IT-Rat) vertreten durch ein Arbeitsgremium
Interessenvertreter (Stakeholder) SAGA-Expertenkreis, die Dienstleistungszentren des Bundes, die KoopA-SAGA-Projektgruppe und die interessierte Öffentlichkeit
Tabelle 2: Rollen und Besetzungen im Änderungs-Management für SAGA
Die Abbildung auf der folgenden Seite zeigt zunächst den Fortschreibungsprozess für eine neue
SAGA-Hauptversion.
Auch hierbei wurden die unterschiedlichen Rollen nach dem Vorbild des V-Modells XT benannt und
sollen wie folgt besetzt werden:
Rolle Besetzung
Auftraggeber Der Rat der IT-Beauftragten der Ressorts (IT-Rat) vertreten durch ein Arbeitsgremium
Auftragnehmer Der Beauftragte der Bundesregierung für Informationstechnik (BfIT) vertreten durch das Referat IT 2 des BMI unterstützt durch ein Autorenteam, in das andere Ressorts auch Mitglieder entsenden können
Interessenvertreter (Stakeholder) SAGA-Expertenkreis, die IT-Dienstleistungszentren des Bundes, die KoopASAGA-Projektgruppe und die interessierte Öffentlichkeit.
16 Konzept für SAGA 5.0
Tabelle 3: Rollen und Besetzungen in den Fortschreibungsprozessen von SAGA
Im Rahmen von Workshops zwischen Auftraggeber und Auftragnehmer werden
• das Pflichtenheft erstellt;
• Vorschläge des SAGA-Autoren-Teams noch vor der Erstellung der Alpha-Version diskutiert;
• die Alpha-Version abgestimmt;
• der Umgang mit Stellungnahmen zur Beta-Version abgestimmt;
• SAGA finalisiert (ggf. nach Anweisungen vom BfIT, vom IT-Rat oder von der IT-
Steuerungsgruppe des Bundes).
17 Konzept für SAGA 5.0
Abbildung 4: Fortschreibungsprozess einer Hauptversion von SAGA
Auch nach der Publikation einer finalen SAGA-Version kann es notwendig werden, auf aktuelle
Entwicklungen zu reagieren. Falls Sicherheitsstandards kompromittiert wurden, müssen diese
ausgetauscht werden. In diesem Fall würde der IT-Rat über Modifikationen der aktuellen SAGA-
Version entscheiden. Für eine Zwischenversion sieht der Fortschreibungsprozess entsprechend wie
folgt aus:
18 Konzept für SAGA 5.0
Abbildung 5: Fortschreibungsprozess einer Zwischenversion von SAGA
4.3 Projekt zur Erstellung von SAGA 5.0
Für die Erstellung von SAGA 5.0 würden die folgenden zusätzlichen Aufgaben auf Auftraggeber und
Auftragnehmer hinzukommen:
• die Grundlagen von SAGA 5.0 abstimmen und ausformulieren
• die zu behandelnden Themenbereiche für technische Standards abstimmen
• Bewertungskriterien für Standards transparent ausformulieren
• das neue Klassifikationssystem anhand der bestehenden Standards in SAGA erproben
• über Abfragen in den Ressorts ermitteln, welche Standards die Klassifikation „Verbindlich“
erhalten können
• Publikationsform(en) konzipieren
• die Vorlagen (Kriteriengruppe, Angebot, Konformitätserklärung) das für das Vorgehen zur
Erreichung von SAGA-konformen IT-Lösungen18 aktualisieren und auf der SAGA-
Homepage veröffentlichen
18 Siehe Abschnitt 3.7 „Konformität“ ab Seite 12