Kapitel 3 Kriterien für erfolgreiche Migrationen Für eine erfolgreiche Software-Migration     ist die Klärung   der technischen   Umstände   eine notwendige, aber keine hinreichende Bedingung. Vielmehr ist eine Reihe weiterer Kriterien zu beachten, die für einen reibungslosen Migrationsverlauf erfüllt sein müssen. Diese allgemeinen Kriterien werden nachfolgend vorgestellt. Besonders zu beachten ist der Abschnitt 3.2 zur Vorgehensweise, der für verschiedene Migrationstypen die jeweils relevanten Kriterien und Schritte nennt. Er dient damit als Wegweiser durch die verschiede- nen Kriterien dieses Kapitels. 3.1      Ziele einer Migration Vor einer Migration müssen zunächst deren unmittelbare Ziele geklärt werden. Diese leiten sich entwe- der aus erkannten Schwachstellen oder notwendigen Erweiterungen der Bestandssoftware ab, oder sie sind betriebswirtschaftlicher oder strategischer Natur. Häufige Migrationsziele sind k   . ein verbesserter Anwendernutzen, D     das Herstellen eines rechtlich notwendigen Zustands, Q     die Behebung von Fehlern, D     die Erweiterung des Funktionsumfangs, eine verbesserte Integration in die vorhandenen Softwaresysteme, OM    eine verbesserte Interoperabilität, N     eine Verringerung der laufenden Kosten, d     die Erhöhung der Produktivität, ©     die bessere Nutzung vorhandener Resourcen sowie cl S     die Einhaltung strategischer Vorgaben (siehe 3.3). Nach der Erfassung der jeweiligen Migrationsziele müssen sie gewichtet oder priorisiert werden, da sie die Grundlage für die Auswahl der künftigen Software darstellen. Die nachfolgend dargestellten Aspekte unterstützen die Zielerreichung und können jeweils einem oder mehreren der erfassten Ziele zugeordnet werden.

22                                                                               3 Kriterien für erfolgreiche Migrationen 3.2            Vorgehensweise / Migrationsplanung Es existieren verschiedene Vorgehensmodelle für Software-Migrationen. In einem Beitrag (Win08) zum BMBF-Forschungsprojekt „Flexible Informationssystem-Architekturen für hybride Wertschöpfungsnetz- werke (FlexNet)“ wurden deren wesentliche Aussagen zusammengeführt zu einem Vorgehensmodell, das die verschiedenen          Phasen einer Software-Migration anschaulich beschreibt. Die in dem                Beitrag durchgeführte weitreichende Analyse führt dazu, dass sich der Migrationsleitfaden an das in Abbildung 3.1 dargestellte Modell anlehnt. |Makrophase -                      Mikrophase                                        Methodik e             e Projekt-     - Unternehmensvorstellung vorstellung     - Projektmanagement - Problemausarbeitung Projektplanung            V                     - Strategische Planungsmethoden - Zielformulierung Projekt-       - eingrenzung Ö                  —_                   [ z                                                     Ist-        - Fragebogen r                                               Analyse       - Experteninterviews S                                           L                     - Dateianalyse ©                  Soll-Konzeption          \///                  - Beobachtung E                                               Schwachstellen-   |- Kriterienkatalog “            ©                                      analyse       7 Marktsichtung               Vorauswahl - Fachliteratur D                    - 7 —/                     - Pusbllikationen Funktionale             Wirtschaftliche   | Produktun_formatpnen r                       B       rtun              Bewertung       - Referenzinstallationen S                           Swertung                              - Webrecherche ©                 \\/                       \/                    - TCO ;             D                                               N © ’               \Ri3ikoiflyi/                                   - Sensitivitätsanalyse —         Entscheidungsempfehlung RE Abbildung 3.1: Vorgehensmodell für Software-Migrationen (Win08) Das Vorgehensmodell in Abbildung 3.1 unterteilt sich in Makrophasen, Mikrophasen und Methodik. Die Makrophasen beschreiben die drei Hauptphasen in diesem Modell. Die Mikrophasen verfeinern die Makrophasen        anhand durchzuführender Projektschritte, die parallel oder sequentiell ablaufen können. Neben jeder Mikrophase befindet sich ein Textblock mit möglichen anzuwendenden                        Methoden für die entsprechende Makrophase (vgl. (Win08) S.6).

3.2 Vorgehensweise / Migrationsplanung                                                                                    23 Das Modell beginnt mit einer projektvorbereitenden Einführungsphase, in der die genaue Planung und Meilensteine gesetzt werden können. Die Anforderungsanalyse als zweite Makrophase beschäftigt sich detaillierter mit der Behörde und den gestellten Anforderungen aus Behördensicht und ist die Grundla- ge für die Herangehensweise in den einzelnen Technologiefeldern des Kapitels 4. Die darauf folgende Auswahlphase       umfasst den Kern des Entscheidungsproblems — den Vergleich und die Bewertung ver- schiedener Produkte des jeweiligen Migrationsgebiets sowie daraus resultierender Empfehlungen. Die Umsetzung als letzte Phase geht auf die verschiedenen Migrationswege und deren Auswirkungen ein. 3.2.1       Einführungsphase Der Migrationsleitfaden beschreibt nachfolgend das Vorgehen                    bei einer Software-Migration.      Für eine Migration müssen einige Voraussetzungen erfüllt sein: | Die Notwendigkeit einer Software-Migration ist in der Behörde gegeben. 1   Die Gründe dafür sind dem         IT-Entscheider grundsätzlich bekannt. 4     Über die IT-Planung sind bereits Haushaltsmittel veranschlagt. 1   Es handelt sich nicht um eine Aktualisierung (siehe Abschnitt 2.1.1). Der IT-Entscheider muss nun einige Schritte veranlassen, um aus diesen Voraussetzungen ein Vorha- ben zu formen. Zunächst ist das Vorhaben mit einem griffigen Namen zu versehen; Pseudonamen mit angehängtem „neu“ 0.ä. sind zu vermeiden. Sodann müssen die ggf. nur oberflächlich bekannten Grün- de konkretisiert und gewichtet werden. Aus den gewichteten Gründen sind die unmittelbaren Ziele der Migration und ihre jeweilige Priorität herzuleiten. Dazu müssen die in 3.1 genannten beispielhaften Ziele auf den konkreten Fall angepasst und die jeweiligen Spezifika beschrieben werden. Zudem sind wesent- liche Auswirkungen auf die Interoperabilität mit anderen in- und externen Systemen abzuschätzen und das Migrationsvorhaben von anderen IT-Projekten und organisatorischen Veränderungen abzugrenzen. Die wichtigsten Rollen im Migrationsvorhaben müssen festgelegt und mit geeigneten Personen besetzt werden. Das ggf. vorhandene IT-Architekturmanagement ist bei jedem Migrationsvorhaben einzubezie- hen. Sofern die Migration von zentraler Bedeutung ist oder wesentliche Elemente des derzeitigen Ge- samtsystems beeinflusst, ist auch die Behördenleitung zu involvieren und das Vorhaben behördenweit abzustimmen. Einbeziehung und Abstimmung sind dauerhaft anzulegen, beispielsweise durch regelmä- Bige Statusbesprechungen, um eine langfristige Unterstützung und Aufmerksamkeit der Leitungsebene für das Vorhaben zu gewinnen und es transparent voranzutreiben. Das V-Modell XT Bund (Der10) enthält im Teil 1 unter „3.2 Projektgenehmigung und Projektstart“ eine Beschreibung der für die Einführungsphase notwendigen Produkte'. Zwar liegt der Schwerpunkt des V-Modells in der Systementwicklung, doch kann die Beschreibung analog auf Migrationsvorhaben an- gewandt werden. Die Definition des dort genannten Produkts „Projektauftrag“ fasst einige der 0.g. und weitere Aspekte folgendermaßen zusammen: „Der Projektauftrag schafft die grundlegenden             organisatorischen       und rechtlichen   Rahmen- bedingungen für die Projektdurchführung. Das Dokument benennt den Projektleiter, den Pro- jektmanager sowie den Lenkungsausschuss und definiert die Ziele, den Zeitrahmen und das Budget.“ Der Projektauftrag bildet die Grundlage des weiteren Vorgehens und ist je nach Relevanz und Auswir- kungen des Migrationsvorhabens von der Behördenleitung oder vom                        IT-Entscheider zu erteilen. 3.2.2       Anforderungsanalysephase Die Anforderungsanalysephase beginnt mit erteiltem Projektauftrag. Je nach Größe des Vorhabens sind ein Projektbüro zur Unterstützung der Projektleitung einzurichten und geeignete Personen für die An- ! Ein Produkt im Sinne des V-Modells ist ein Ergebnis einer Projektphase, beispielsweise ein bestimmtes Dokument.

24                                                                            3 Kriterien für erfolgreiche Migrationen forderungsanalyse zu bestimmen. Das Vorgehen bei der Anforderungsanalyse ist spezifisch für die ein- zelnen Technologiefelder in den einzelnen Abschnitten des Kapitels 4 beschrieben, unterschieden in die Analyse des Ist- und die Konzeption des Soll-Zustands. Die grundlegenden Aspekte dieser Phase sind nachfolgend stichpunktartig aufgeführt: 1. Ist-Analyse vorbereiten (1)   Projektbüro einrichten (2) Analysephase detailliert planen (3)   Prüflisten, Fragebögen, etc. für die Ist-Analyse erstellen (4) Interviewpartner bei vielen betroffenen Anwendern in Gruppen einteilen (5)5) Analysten zu Interviewpartnern / Gruppen zuordnen 2. Ist-Analyse durchführen und folgende Aspekte erfassen: (1)   Derzeit eingesetzte Software samt Version und genutzten Komponenten (2) Genutzte Funktionalität, festgestellte Probleme und Funktionslücken (3)   Standard-Datenformate und zusätzlich benötigte Formatunterstützung für Abwärtskompatibilität oder Export (4)   Erweiterungen (Plug-Ins), Eigenentwicklungen u.ä. (5)   Domänenspezifische Bewertungskriterien (6) Wirtschaftliche Rahmenbedingungen          (z.B. bewilligte Haushaltsmittel) (7)   Strategische Rahmenbedingungen        (z.B. IT-Ratsbeschlüsse) (8)   Relevanz und Priorität der genannten Aspekte 3. Ist-Analyse auswerten (1) Gewonnene        Erkenntnisse konsolidieren und strukturieren (2)   Liste mit Mindest-Anforderungen an die Basisfunktionalität erstellen (3) Liste mit spezifischen Zusatz-Anforderungen erstellen 4. Soll-Konzeption durchführen (1) Aus Ist-Analyse gewonnene        Anforderungen prüfen und um fehlende, ggf. domänenspezifische Aspekte ergänzen (2)   Einzelne Anforderungen dem umsetzenden Teilsystem zuordnen und ggf. von parallelen Vorha- ben abgrenzen (3)   Einzuhaltende offene Standards festlegen (4) Ggf. Externe über künftige Standards frühzeitig informieren (5) Weiterverwendung vorhandener Erweiterungen und Eigenentwicklungen klären (6) Ggf. Übergabe von Eigenentwicklungen an IT-Betrieb planen (7) Anforderungen priorisieren Qualitative Aspekte und Aspekte des Systembetriebs sind ebenfalls zu berücksichtigen und fließen meist in nichtfunktionale Anforderungen ein. Zudem sind die übrigen in Kapitel 3 genannten Aspekte zu be- rücksichtigen. Das Resultat der Analysephase ist eine Beschreibung der funktionalen und nichtfunktionalen Anforde- rungen an das künftige System sowie eine Skizze der Gesamtsystemarchitektur.                      Es entspricht dem Produkt „Anforderungen (Lastenheft)“ des V-Modells?. ? Siehe (Der10), Teil 5 Nr. 3.6.5

3.2 Vorgehensweise / Migrationsplanung                                                                   25 3.2.3        Auswahlphase Anhand der erstellten und priorisierten Anforderungen müssen nun die grundsätzlich in Frage kommen- den Alternativen des jeweiligen Technologiefelds bestimmt werden (Marktsichtung und Vorauswahl). Diese sind anhand der Anforderungen miteinander zu vergleichen, um das Produkt mit der größtmögli- chen Anforderungsabdeckung zu ermitteln. Für wichtige Technologiefelder enthält der Migrationsleitfaden im Kapitel Migrationsgebiete eine Voraus- wahl an Produkten, einen Vergleich anhand der für die jeweilige Technologie wichtigsten funktionalen Bewertungskriterien und daraus abgeleiteten Empfehlungen. Die Bewertungskriterien müssen um do- mänenspezifische Aspekte ergänzt und in ihrer Wertigkeit gewichtet werden, um ein für die konkrete Situation belastbares Gesamtergebnis zu erhalten. Zudem müssen die in den Abschnitten Strategische Aspekte und Sicherheitsaspekte genannten Kriterien bewertet und angemessen gewichtet werden. Die Empfehlungen helfen bei der Wahl zwischen ähnlich bewerteten Alternativen. Bei Migrationen von Fachverfahren, die selbst oder im Auftrag entwickelt werden, sind außerdem Qua- litative Aspekte zu bewerten. Diese Kriterien können im Zweifel auch bei Migrationen zu Standard- Produkten angelegt werden. Das so ausgewählte Produkt muss in seiner Wirtschaftlichkeit bewertet werden. Die wichtigsten Punkte dazu sind in Abschnitt Wirtschaftliche Aspekte beschrieben. Der Abschnitt enthält zudem einen Verweis auf ein Begleitdokument mit einer detaillierten Wirtschaftlichkeitsbetrachtung für Migrationen. Schließlich sind die mit einer Migration verbundenen Risiken abzuschätzen. Hierzu sind die Umsetzbar- keit der Anforderungen zu bewerten®, Rechtliche Aspekte von Software-Migrationen zu betrachten und die allgemeinen Risiken des Projektgeschäfts wie Personalfluktuation, unerwartete technische Schwie- rigkeiten oder steigende Kosten zu berücksichtigen. Bei Software-Migrationen müssen zudem die Auswirkungen der Veränderungen auf Anwender und Sys- tembetrieb sowie deren Wechselbereitschaft eingeschätzt und ggf. aktiv gefördert werden, insbesonde- re durch frühzeitige und regelmäßige Informationen über das Vorhaben und dessen Hintergründe. Die wesentlichen        Kriterien hierzu sind in den Abschnitten Aspekte des Systembetriebs  und Organisatori- sche Aspekte dargestellt. Die Beachtung dieser Kriterien senkt das Risiko mangelnder Akzeptanz oder Ablehnung des Migrationsvorhabens durch die Betroffenen. 3.2.4        Umsetzung Die getroffene Entscheidung wird umgesetzt durch die Einführung der neuen Software und die Ablösung der alten. Dabei sind verschiedene Wege möglich (siehe Abschnitt 2.1.4): die Stichtagsumstellung oder die schrittweise Migration. 3.2.4.1       Stichtagsumstellung Die Stichtagsumstellung bietet eine Reihe von Vorteilen. Einem überschaubaren Planungszeitraum folgt ein eindeutiges, vorab festgelegtes Ende der Umstellungsphase, es besteht keine Notwendigkeit für einen lang anhaltenden Parallelbetrieb verschiedener Systeme, die Kosten einer solchen Migration las- sen sich relativ einfach berechnen, die nötigen organisatorischen Schritte gut terminieren. Die Adminis- tratoren und Benutzer werden zwar intensiv, dafür aber nur einmal mit Neuerungen konfrontiert. Zudem müssen sich erstere nicht über längere Zeiträume mit der Komplexität paralleler oder heterogener Wel- ten auseinandersetzen. Eine Stichtagsumstellung birgt allerdings hohe Anforderungen an die Organisation des Projekts und der betroffenen Behörde, an die Technik und an die Finanzen. Die Projektplanung verdichtet sich zum Um- stellungszeitraum hin stark, alle zur Durchführung notwendigen Schritte müssen bedacht und eingeplant und die Verfügbarkeit der Projektmitarbeiter für zu erwartende Lastspitzen über das normale Arbeitspen- 3 vgl. (Der10), Teil 5 Nr. 3.6.6 Anforderungsbewertung

26                                                                          3 Kriterien für erfolgreiche Migrationen sum hinaus gewährleistet sein. Zeitliche Puffer für unerwartete Ereignisse sind nur in geringem Umfang möglich, Abweichungen von der Planung führen schnell zum (vorläufigen) Scheitern der Umstellung. Die Behörde muss eine schnelle und punktgenaue Qualifizierung ihrer Mitarbeiter organisieren, damit diese weiterhin ihren täglichen Pflichten nachgehen können und Störungen des Behördenbetriebs mini- miert werden. Es müssen auf einen zeitlichen Punkt konzentrierte Umstellungs- und Rollout-Konzepte entwickelt, alle Betroffenen frühzeitig informiert und zur Unterstützung des Vorhabens motiviert wer- den. Die benötigten Finanzmittel müssen innerhalb eines kurzen Zeitraums verfügbar sein, die in die Mittelfreigabe einzubeziehenden Stellen sollten rechtzeitig informiert und ggf. für eine beschleunigte Bearbeitung motiviert werden. Stellt das künftige System    erhöhte Anforderungen an die vorhandene          |T-Infrastruktur oder die Ausstat- tung der Arbeitsplätze, müssen die künftig benötigten Ressourcen rechtzeitig beschafft und bereitge- stellt werden. Je nach Beschaffungsvolumen sind entsprechend lange Ausschreibungszeiträume einzu- planen. Außerdem müssen die beschafften Ressourcen bestmöglich für die Aufnahme in das Gesamt- system vorbereitet und insbesondere Betriebssysteme, Basis- und Fachanwendungen mit dem jeweils aktuellen Stand rechtzeitig vor dem Umstellungszeitraum aufgespielt werden. Hierfür sind ggf. zusätzli- che Software-Lizenzen notwendig, die ebenfalls rechtzeitig beschafft werden müssen. Die Hauptlast einer Stichtagsumstellung tragen die Administratoren und Anwender — umso                     mehr, je weniger Know-how bezüglich der neuen IT-Landschaft bei ihnen vorhanden ist. Zwar müssen sich die Administratoren nicht über einen längeren Zeitraum mit verschiedenen IT-Ausrichtungen auseinander- setzen und können sich schon bald ausschließlich auf die neuen Systeme konzentrieren. Doch müssen sie viel Geduld und Überzeugungswillen aufbringen, bis alle Betroffenen effizient mit der neuen Technik umgehen können und die durch den Wechsel bedingten Schwierigkeiten ausgeräumt sind. Für eine Stichtagsumstellung sollte daher eine überschaubare und nicht übermäßig verzahnte Software- Landschaft vorliegen, in der nur wenige Anwendungen und Dienste für die Aufgabenerfüllung eingesetzt werden. Dies kann bei großen Behörden mit wenigen Server-basierten Fachanwendungen genauso der Fall sein wie bei kleineren Behörden mit Standardbüromitteln. Auch hier kann ein leistungsstarkes |T- oder übergreifendes Architekturmanagement in der jeweiligen Behörde helfen. Des Weiteren sollten un- ter den Administratoren    bereits erste Erfahrungen     mit dem   Migrationsziel vorliegen, ggf. aus anderen Teilsystemen oder dem privaten Umfeld. Das kann durch frühzeitige detaillierte Informationen und ent- sprechende     Fortbildungen  gefördert werden.    Schließlich sollte bei der Mehrzahl       der Betroffenen eine gewisse Offenheit für Neuerungen vorhanden sein, die die Ablehnung von Änderungen überwiegt. Sind diese Voraussetzungen       gegeben,  stellt die Stichtagsumstellung ein sinnvolles Vorgehen           dar. An- dernfalls ist es empfehlenswert, die Umstellung schrittweise anzugehen. 3.2.4.2    Schrittweise Migration Bei einer schrittweisen Migration können Behörden und            Verwaltungen die notwendigen Kosten der Haushaltslage angepasst verteilen. Fehlendes Know-how            kann sukzessive aufgebaut werden. Beste- hende Widerstände können langsam abgebaut und Vorbehalte aufgelöst, komplexe IT-Strukturen Stück für Stück zerlegt und neu aufgebaut werden. Die Aufteilung der Migration vieler Arbeitsplätze in kleinere Lose reduziert die Anforderungen an die Anwenderbetreuung und die Systemadministration. Mit jedem erfolgreich absolvierten Schritt steigt die Motivation der Projektbeteiligten, sie gewinnen zudem an Er- fahrung und können die bisherigen Prozesse verbessern. Die Anwender wiederum werden nicht mit zu vielen gleichzeitigen Änderungen überfordert. Allerdings ist ein hoher Planungsaufwand vonnöten, der sich über einen langen Zeitraum erstreckt und kontinuierlich an den Projektverlauf angepasst werden muss. Bei jedem einzelnen Migrationsschritt kön- nen unerwartete Schwierigkeiten auftreten oder aufwendige Zwischenmaßnahmen notwendig werden, die den weiteren Migrationsverlauf hemmen können. Die Administratoren und Anwenderbetreuer müs- sen über den gesamten Zeitraum hinweg ein heterogenes Gesamtsystem abdecken. Die Akzeptanz des Gesamtvorhabens hängt bei allen Beteiligten stark vom Erfolg der ersten für sie spürbaren Schritte ab. Anfängliche Fehlschläge können schnell zu einem negativen Gesamteindruck führen und die Akzeptanz

3.2 Vorgehensweise / Migrationsplanung                                                                      27 deutlich verringern. Bei einer langen Gesamtlaufzeit muss auch verstärkt mit Wechseln beim Projektper- sonal gerechnet werden, was Übergabe- und Einarbeitungsaufwand mit sich bringt und auch taktische oder strategische Änderungen zeitigen kann. Die Unterstützung des Vorhabens durch die Leitungsebe- ne kann über die Projektzeit durch geänderte Rahmenbedingungen            abnehmen    oder der Mittelzufluss durch wechselnde politische Prioritäten schwanken. Eine schrittweise Migration empfielt sich, wenn mehrere funktionale Einheiten oder eine große Zahl von Arbeitsplätzen migriert werden sollen. Zwar ist der Projekterfolg auch bei dieser Vorgehensweise nicht garantiert, doch kann entspannter auf einzelne Schwierigkeiten reagiert werden. Planung und Prozesse können stetig optimiert und an das konkrete Projektumfeld angepasst werden. Bei der Migration    einzelner Produkte  sollte eine schrittweise  Migration nicht vorschnell  als irrelevant ausgeschlagen werden, da es einerseits auf die Art der Migration ankommt (siehe 2.1) und anderer- seits ggf. die Vielzahl umzustellender   Einzelsysteme   mit einer entsprechend    stark ansteigenden    Zahl von Support-Anfragen verbunden sein kann, die zeitlich verteilt werden muss, um die Anwenderunter- stützung nicht zu überfordern. Allerdings sollte das Vorhaben zeitlich nicht überstrapaziert werden, um Langläufer-Probleme wie sich ändernde Leitungsvorgaben oder Personalwechsel zu vermeiden. Auch sollten nicht zu viele funktionale Einheiten in die Migrationsplanung aufgenommen, sondern ggf. in mehrere sich überlappende Migratio- nen mit je eigenem Projektteam aufgeteilt werden. Das bringt zwar zusätzlichen Abstimmungsaufwand mit sich, vermeidet aber die Überforderung eines einzelnen Projektteams und bietet die Möglichkeit zu klaren Abgrenzungen des Projektauftrags. 3.2.5      Kompetenzzentrum Open-Source-Software Das Kompetenzzentrum Open-Source-Software (CC OSS)* in der Bundesstelle für Informationstechnik des Bundesverwaltungsamtes fördert den Einsatz von offenen Standards und Open-Source-Software (OSS) in der Bundesverwaltung. Interessierten Bundesbehörden bietet das CC OSS Hilfestellung bei den wesentlichen OSS betreffenden Belangen. Dazu gehört insbesondere die Beratung von der Ent- scheidungsfindung über die Produktauswahl bis zur Migrationsberatung. Außerdem pflegt das Kompe- tenzzentrum OSS ein Netzwerk von Erfahrungsträgern und kann darüber Ansprechpartner für gezielte Fragestellungen vermitteln. 4 http://www.oss.bund.de/

28                                                                           3 Kriterien für erfolgreiche Migrationen 3.3       Strategische Aspekte Bei der Migrationsplanung sind neben den unmittelbaren Zielen (siehe 3.1) auch strategische Erwägun- gen einzubeziehen. Bundesbehörden stehen im regen Datenaustausch mit anderen Behörden, mit Wirt- schaftsbeteiligten und mit Bürgern. Die IT-Rahmenplanung des Bundes muss ebenso beachtet werden wie architektonische oder Format-Vorgaben des SAGA-Rahmenwerks. Zudem gilt es, die zunehmend verfügbaren    Dienstleistungen der DLZ-IT zu berücksichtigen und ggf. in Anspruch              zu nehmen.     Die zu beachtenden strategischen Aspekte umfassen folglich !_   die generelle SAGA-Konformität, i    die Beachtung    der in SAGA   genannten     grundlegenden    Kriterien wie Offenheit, Agilität und Wie- derverwendbarkeit, '    die Herstellerunabhängigkeit und Stärkung des Wettbewerbs durch die Verwendung                    und Einfüh- rung offener Standards und Protokolle, die Harmonisierung der Software-Strategien der Bundesbehörden               und die Vereinheitlichung der Standard-Softwarelandschaft in den Bundesbehörden, die Konzentration des internen Know-Hows auf Standard-Komponenten und deren Wiederverwen- dung, !_  die Konzentration von externen Dienstleistungen auf wenige Standard-Komponenten, !   die Schaffung rechtlicher Klarheit, insbesondere bei bisher unkontrolliert eingesetzter OSS, sowie |    die dauerhafte Wirtschaftlichkeit über einen Zeitraum von sieben bis zehn Jahren. Bei jeder Änderung des bestehenden Systems sollte daher geprüft werden, welche Teilsysteme und Komponenten auch künftig Teil der IT-Strategie sein oder ggf. zusammen mit dem eigentlichen Migrati- onsobjekt abgelöst werden sollen. Auch seit langem etablierte Bestandteile gehören immer wieder neu auf den Prüfstand, um die Auswirkungen deren Einsatzes auf das Gesamtsystem und deren Konformität zu strategischen Vorgaben zu beleuchten. Mit diesen Überlegungen       stehen der IT-Rat und die deutschen      Bundesbehörden         nicht alleine, wie das Beispiel der IT-Strategie der britischen Regierung zeigt. Diese will laut ihrem Cabinet Office bei den IT-Kosten sparen und sich zugunsten       kleinerer, flexiblerer Projekte von Großinstallationen verabschie- den (Cab11). In Zukunft soll mehr Open-Source-Software eingesetzt und eine zentrale Website der Verwaltung eingerichtet werden. Außerdem weist sie auf die Bedeutung von Interoperabilität durch die Verwendung offener Standards hin und regt das Teilen und Wiederverwenden von IT-Systemen und -Services im Public Sector an. Der Migrationsleitfaden unterstützt den Prozess der Prüfung, der Beleuchtung von Alternativen und der Entscheidungsfindung, indem er die zu betrachtenden Aspekte prozessorientiert beschreibt, Bewer- tungskriterien aufstellt und daraus abgeleitete Empfehlungen ausspricht.

3.4 Rechtliche Aspekte                                                                                                    29 3.4        Rechtliche Aspekte Jede Software-Migration muss die rechtlichen Aspekte des künftigen Teilsystems beleuchten. Je nach Art und Herkunft der künftigen Software ergeben sich beispielsweise Rechtsfragen in Bezug auf zugesi- cherte Eigenschaften, Gewährleistung, Verwendungsmöglichkeiten, Dienstleistungen wie Einrichtungs- und Betriebsunterstützung, Anzahl erlaubter Installationen oder Verwendung in virtualisierten Umge- bungen. Zudem steht eine Migrationsentscheidung stets unter der Prämisse der vergaberechtlichen Zulässigkeit. Diese Fragen sind prinzipiell unabhängig von der mit der Software verbundenen Lizenz zu klären. Beim    Bezug    proprietärer    Software   müssen    alle regelungsbedürftigen        Aspekte     für deren   Einsatz  mit dem Hersteller oder Anbieter vertraglich vereinbart werden. Die Software darf ausschließlich im vertrag- lich vereinbarten Umfang genutzt werden, Art und Umfang der Ansprüche gegen den Vertragspartner sind vertraglich geregelt. Diese vertragliche Fixierung begründet eine gewisse Rechtssicherheit, die bei Open-Source-Software oft nicht vermutet wird. Die Rechtsfragen, die sich beim Einsatz von OSS stellen, bieten bei näherer Betrachtung allerdings kein stichhaltiges Argument gegen die Verwendung durch Behörden. Die Vereinbarkeit des Lizenzmodells mit den relevanten Normen des Urheber-, Patent-, Haushalts- und Verwaltungsrechts wurde in den letzten Jahren mehrfach von deutschen Gerichten bestätigt. Auch hat der Gesetzgeber Bestimmungen in das Urheberrechtsgesetz aufgenommen, die zur rechtlichen Absicherung der GNU General Public License und der anderen OSS-Lizenzen beigetragen haben. Die Beherrschbarkeit der rechtlichen Risiken zeigt sich im Übrigen daran, dass in Deutschland keine Fälle bekannt geworden sind, bei denen Nutzer von OSS wegen Rechtsverstößen rechtlich belangt worden sind. Die rechtlichen Risiken sind in der Summe deswegen       nicht gravierender als bei herkömmlich lizenzierten Programmen®. Aus der Sicht einer Behörde sind zwei Szenarien zu unterscheiden. In vielen Fällen haben Behörden keine über die reine Nutzung         hinausgehenden       Rechte an der in Frage stehenden            OSS, weil sie diese weder geschrieben noch modifiziert haben. Die Behörde nutzt die Software dann als Lizenznehmer nach Maßgabe der jeweiligen OSS-Lizenz (hierzu sogleich unter 3.4.1). Hiervon zu unterscheiden ist der Fall, in dem    die Behörde      ein selbst entwickeltes    Programm       anderen    Behörden    oder Privaten als OSS       zur Verfügung stellt bzw. ein vorbestehendes OSS-Programm in veränderter Form weitergeben möchte. In diesem Fall ergeben sich zusätzliche Rechtsfragen (hierzu unter 3.4.2). 3.4.1       Behörde        als Nutzer und        Lizenznehmer Bei der Nutzung von OSS wird oftmals übersehen, dass für die bestimmungsgemäße                           Benutzung eines Programms nicht der Abschluss eines Lizenzvertrags erforderlich ist. Dies ergibt sich aus 8 69d Abs. 1 UrhG. Sofern eine Behörde OSS auf einem Datenträger erwirbt oder aus dem Internet herunterlädt und das Programm lediglich benutzt, ohne es zu vervielfältigen, zu verbreiten, öffentlich zugänglich zu ma- chen oder zu verändern, so ist der Abschluss eines OSS-Lizenzvertrags nicht erforderlich. Die Rechte und Pflichten der GNU General Public License oder anderer OSS-Lizenzen sind für die Behörde dann ohne Bedeutung. Erwirbt die Behörde das Programm in diesem Fall entgeltlich, etwa durch den Kauf ei- ner kommerziellen Distribution, so bestehen gegen den Verkäufer die normalen Mängelgewährleistungs- und Haftungsansprüche. Hier ergeben sich keine Unterschiede zur Anschaffung proprietärer Software. Hat die Behörde die Software dagegegen kostenlos erhalten, so bestehen Ansprüche auf Mängelge- währleistung nur, wenn die Mängel arglistig verschwiegen wurden. Auch haftet die Person, von der die Behörde das Programm erworben hat, für sonstige Schäden nur bei grober Fahrlässigkeit. Diese we- niger weitreichende Haftung ergibt sich aus der Anwendung der Vorschriften zum Schenkungsvertrag, weil es sich um eine unentgeltliche Überlassung handelt. 5 Siehe auch   Unterlage für Ausschreibung und Bewertung   von IT-Leistungen (UfAB V) Version 2.0, insbesondere 4.42 MODUL: Beschaffung von Open Source Software

30                                                                               3 Kriterien für erfolgreiche Migrationen Nur wenn die Behörde die Software vervielfältigt, verbreitet, verändert oder öffentlich zugänglich macht, bedarf sie der Rechte aus der betreffenden OSS-Lizenz. Erst bei dieser gesteigerten Nutzung kommt es also zum Abschluss eines Lizenzvertrags. Die üblichen OSS-Lizenzen gewähren der Behörde in diesem    Fall weitreichende Nutzungsrechte. Allerdings beinhalten die OSS-Lizenzen                     auch mehr oder weniger weitreichende       Pflichten, die die Behörde    einzuhalten hat. Alle OSS-Lizenzen            verpflichten den Lizenznehmer dazu, mit jeder Kopie des Programms auch eine Kopie des Lizenztexts mitzuliefern und die Hinweise auf die Geltung der Lizenz unverändert mitzuverbreiten. Typisch ist auch die Pflicht, einen Haftungs- und Gewährleistungsausschluss und die bestehenden Copyright-Vermerke unverändert mit- zuverbreiten. Dagegen sehen nur einige OSS-Lizenzen die Pflicht vor, die Quelltexte des Programms zur Verfügung zu stellen. Dieses Grundgefüge der Rechte und Pflichten wurde von deutschen Gerichten am Beispiel der GNU General Public License Version 2 und der GNU Lesser General Public License Version 3 für wirksam erklärt. Behörden können sich also darauf verlassen, dass sie entsprechende Rechte aus den Lizenzen erwerben können. Der Lizenzvertrag kommt dabei formfrei durch die Inanspruchnahme der Rechte der Lizenz zustande, also beispielsweise durch die Veränderung eines Programms. Wenn    Behörden     Software aktiv verbreiten oder öffentlich zugänglich machen,             so gehen      sie das recht- liche Risiko ein, wegen Verletzung von Urheber- oder Patentrechten in Anspruch genommen                             zu wer- den,   wenn   das   betreffende    Programm    die  Rechte   Dritter verletzt.    In Frage    kommen      in diesem      Fall Schadensersatz- und Unterlassungsansprüche. Behörden können zudem zur Übernahme der Kosten einer Abmahnung durch den Rechtsinhaber verpflichtet sein. Behörden sollten deswegen gerade bei wenig verbrefiteten, erst seit kurzem verfügbaren OSS-Programmen sorgfältig prüfen, ob geistige Ei- gentumsrechte Dritter entgegen stehen, bevor sie das Programm weitergeben. Dies kann z.B. durch die von der FSFE bereitgestellte Tippsammlung® geschehen. Schließlich   sollten Behörden      bei der Beschaffung    von OSS       darauf achten, dass die Regeln           des Ver- gaberechts eingehalten werden. Ausschreibungen              müssen     neutral erfolgen und sollten keine Formu- lierungen enthalten, durch die Anbieter proprietärer Software von vornherein ausgeschlossen werden. Bei der Forderung nach der Einhaltung offener Standards dürfte dies stets gegeben sein. Auch dürfen typische Eigenschaften von OSS, insbesondere die Verfügbarkeit der Quelltexte, die Unabhängigkeit von einzelnen Anbietern beim Support sowie die Möglichkeit des Rechtserwerbs, durchaus gefordert werden. Die genannten Kriterien sollten in der Ausschreibung transparent gemacht werden, damit sie bei der Vergabeentscheidung berücksichtigt werden können. Werden diese Grundsätze eingehalten, so ergeben sich keine vergaberechtlichen Probleme bei der Anschaffung von OSS. 3.4.2      Lizenzierung verwaltungseigener Software als OSS Wenn die Behörde eigene Entwicklungen oder Fortentwicklungen vorbestehender OSS nach den Be- stimmungen einer OSS-Lizenz anderen Behörden und Privaten zur Verfügung stellen will, ergeben sich andere rechtliche Fragestellungen. Die Behörde ist dann Lizenzgeber im Rahmen des OSS- Entwicklungsmodells. Eine entsprechende       Lizenzierung behördeneigener Software als OSS setzt zunächst voraus, dass die Behörde     Inhaberin der ausschließlichen        Nutzungsrechte     an dem      Programm      ist. Wenn      die in Frage stehenden Programme von Bediensteten des jeweiligen Verwaltungsträgers geschrieben wurden, so können die Rechte auch ohne Abschluss einer besonderen Vereinbarung gem. $& 69b UrhG beim Ar- beitgeber liegen. Der Erwerb ausschließlicher Rechte auf der Grundlage von $ 69b UrhG ist jedoch an enge Voraussetzungen geknüpft. Die Rechtsprechung hat die Vorschrift in der Vergangenheit eher arbeitnehmerfreundlich       ausgelegt.   Der Rechtserwerb     gem.    $ 69b UrhG      muss    deswegen        im Einzelfall geprüft werden. Bei Entwicklungen durch externe Auftragnehmer bedarf es der ausdrücklichen Einräu- mung    ausschließlicher Nutzungsrechte,        damit die Behörde       ein Programm       als OSS     lizenzieren    kann. Zur Sicherheit sollte sowohl bei Bediensteten als auch bei externen Programmierern eine ausdrückliche Einwilligung in die Verwendung als OSS eingeholt werden. Shttp://fsfe.org/projects/ftf/useful-tips-for-vendors.de.html,         abgerufen: 22.02.2012