Konzept für SAGA 5 - cio.bund.de · Dieses Konzept erläutert, wie SAGA auf Basis der Version 4.0 weiter entwickelt werden soll, um es an die neuen Rahmenbedingungen anzupassen und

Konzept für SAGA 5.0

beschlossen vom Rat der IT-Beauftragten am 05.06.2009; Version 1.1

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

[email protected]

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

mailto:[email protected]


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


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.


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.


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.


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


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.


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.


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“


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.


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.


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


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.


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.


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).


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:


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

Documents

Konzept für SAGA 5 - cio.bund.de · Dieses Konzept erläutert, wie SAGA auf Basis der Version 4.0 weiter entwickelt werden soll, um es an die neuen Rahmenbedingungen anzupassen und