11. Phase H: Change Management

11.1 Einleitung zu Phase H

Phase H überwacht und steuert die Weiterentwicklung des Unternehmens. Dazu beobachtet sie Änderungen an den Geschäftsprozessen, beispielsweise aufgrund von Erweiterungen der Dienstleistungsportfolios oder allgemeiner Diversifikationen. Zusätzlich beobachtet sie Innovationen in den eingesetzten geschäftsprozessunterstützenden Techniken, also industrielle Weiterentwicklungen von Hardware und Software sowie neue Trends im optimierten IT-Betrieb. Im Fokus dieser Phase stehen aber auch Beobachtungen und Bewertungen des Reifegrads bezogen auf die erwarteten Ziele, die das Unternehmen mit der umgesetzten Transformation erreicht hat. Ergänzend sind in dieser Phase Risiken zu identifizieren, die den erfolgreichen Geschäftsbetrieb einschränken können.

Mit der bisher umgesetzten Iteration des Architekturentwicklungszyklus SouvAP wurden teils eher kosmetische, teils aber auch gravierende Änderungen an der Ausgangslage dPhoenixSuite erzeugt. In der Umsetzungsphase hat sich herausgestellt, dass die Anforderung „Containerisierung“ Auslöser einer Disruption war, die im Vergleich zu bisheriger Software-Entwicklung und bisherigem Plattform-Betrieb völlig neuartige Herangehensweisen erfordert. Die Nutzbarmachung der ausgewählten Modul-Kandidaten in einer Container-Plattform stellte eine durchaus beherrschbare Aufgabe dar. Bezogen auf moderne Container-native Anwendungen kann diese Art der Nutzbarmachung aber allenfalls als rudimentäre Migration gelten. Um die Vorteile Container-nativer Applikationen nutzen zu können, z.B. horizontal skalierbarer und wartungsfrei modernisierbarer Servicebetrieb, sind mehrheitlich tiefgehende Änderungen an der Applikationsarchitektur benötigt.

Ein weiteres Feld für zeitnah erwarteten Anpassungsbedarf betrifft die Absicherung der containerisierten Plattform, also den robusten Aufbau der Infrastruktur und einen gesicherten Betrieb entsprechend dem anvisierten Schutzbedarf. In der Architekturarbeit wurden diverse, teils weniger populäre Erfordernisse für Sicherheitsmaßnahmen an Container-Plattformen aufgedeckt und diese reichen bis in die Anwendungskodierung. Aktuell sind potenzielle Gefahren und darauf anzuwendende Abwehrmaßnahmen vorwiegend in spezialisierten Foren diskutiert.

In einschlägigen Maßnahmenkatalogen für die Absicherung von Container-Plattformen finden die neu bekannt gewordenen Sicherheitslücken überwiegend noch keine Berücksichtigung. Dieser Umstand ist zweifelsfrei dem hohen Innovationsgrad innerhalb der Container-Technik geschuldet, die in kurzen Zyklen neue Fähigkeiten bereitstellt. Umso dringlicher ist ein kontinuierliches und aufmerksames Studium einschlägiger Foren zum Thema erforderlich. Der daraus erkennbare Bedarf für zusätzliche Absicherung muss quasi im Tagesgeschäft analysiert und mit Umsetzung etwa erforderlicher zusätzlicher Schutzmaßnahmen abgefedert werden.

11.2 Wertschöpfung mit der Zielarchitektur

Die Zielarchitektur wurde für eine optimierte Unterstützung von Geschäftsprozessen mit Informationstechnik entwickelt. Die Transformation sollte die Grundlage für ein neues Niveau der Wertschöpfung mit diesen Geschäftsprozessen liefern. Dabei müssen Wertschöpfungen nicht ausschließlich monetär positiv messbar sein. Z.B. kann ein zusätzlicher Sicherheitsgewinn nur schwer positiv bewertbar sein, da dieser auf die Beschränkung und Kontrollierbarkeit von Verlustpotenzialen abzielt und nicht eintretende Verluste keinen direkten monetären Beitrag zu den unternehmerischen Bilanzen einstreuen. Jedoch sind Verlustereignisse wie die derzeit häufig beobachteten Schäden durch Ransomware (Anhalt-Bitterfeld, Südwestfalen IT und viele Weitere) und Disruptionen der Produktverfügbarkeiten (VMware Erwerb durch Broadcom) signifikant.

Die Zielarchitektur soll aber auch die Voraussetzungen für eine verbesserte Agilität geliefert haben derart, dass eine optimierte Wertschöpfung auch Änderungen an den Geschäftszielen Stand hält. In diesem Zusammenhang sind ggf. Anpassungen an der Zielarchitektur vorzunehmen, sodass die erwartete Wertschöpfung mindestens gelingt und idealerweise noch gesteigert werden kann. Phase H steht in der Verantwortung, den Bedarf an Nachsteuerung an der Zielarchitektur über Änderungen im Unternehmen und in seinem Umfeld frühzeitig zu betrachten und darauf zugeschnittene Maßnahmen zu empfehlen.

11.3 Überwachung wertschöpfungsprägender Domänen

TOGAF empfiehlt, wertschöpfungsprägende Einflussaspekte fortlaufend zu beobachten und daraus abzuleiten, ob und wenn ja welche Anpassungen an der Zielarchitektur anzustreben sind. Dies soll idealerweise werkzeuggestützt erfolgen. Beispiele für dafür geeignete Werkzeuge liefert TOGAF nicht. Es ist anzunehmen, dass ein Werkzeug gemeint ist, das unternehmerisch und anwenderseitig beobachtete interne und wettbewerbsseitige Veränderungen tabelliert und darüber einen Überblick über Anpassungspotentiale geben kann.

Zu beobachtende bzw. zu überwachende Einflussaspekte klassifiziert TOGAF wie folgt:

• Technologieveränderungen
• Geschäftsveränderungen
• Änderungen am Reifegrad der Leistungsfähigkeit der Unternehmensarchitektur
• Anlagevermögen
• Dienstleistungsgüte (Quality of Service QoS)
• Anforderungen an die Geschäftskontinuität

Bezogen auf den SouvAP hält die SouvAP-Architektur die folgenden Domänen für überwachungspflichtig:

• Anforderungen an das Container-Plattform-Design
• Rahmenbedingungen für die Absicherung der Container-Plattform
• Anforderungen an die Nutzbarmachung von auf Open CoDE abgelegten Artefakten
• Anforderungen an Skalierbarkeit
• Anforderungen an die Dienstleistungsgüte
• Anforderungen an Verfügbarkeit/Ausfallsicherheit/Hochverfügbarkeit/Fehlertoleranz
• Anforderungen an container-natives Anwendungsdesign

Die Aufzählung lässt sich grob in die Kategorien Plattform-Fortschreibung, Management des Anwendungs-Lebenszyklus und betriebliche Aspekte clustern. Das war auch eigentlich zu erwarten, denn die bisher mit der Transformation erreichten Reifegrade betreffend Containerisierung und Absicherung von Plattform/Applikationsbündel setzen die in der modernen Literatur zu den Themen diskutierten "Best Practices" noch nicht auf höchstem Niveau um.

Die Container-Plattform sollte laut Projektauftrag konform zu den Vorgaben der Deutschen Verwaltungscloudstrategie aufbereitet werden. Aufgrund des Vorhabens „DVS-Umsetzung“ wurde dies zurückgestellt und alternativ wurde für den Probebetrieb eine Kubernetes-as-a-Service Installation bei einem C5-testierten und BSI-Grundschutz-zertifizierten Partnerunternehmen angemietet. Der Aufbau einer eigenen Kubernetes-Plattform auf Seite des angedachten Betreibers Dataport wurde parallel dazu angestrengt mit dem Ziel, diese zunächst auf die bekannten Anforderungen an eine DVS-Implementierung anzulehnen und diese mit Fortschreiten der DVS-Umsetzung sukzessive auf die Architekturvorgaben zur DVC auszurichten.

Während der Transformation wurde die Containerisierung als ein längerfristig auszugestaltendes Vorhaben identifiziert. In der Steuerung der Transformation wurden daher sicherheitsrelevante Prioritäten gesetzt, die bei der Containerisierung zu adressieren sind. Diese Prioritäten wurden bei der Transformation der Module vollständig umgesetzt. Die Migration der Module hin zum Zielbild „Container-nativ“ wurde jedoch von den am Projekt beteiligten Herstellern einstimmig als längerfristige Aufgabe eingestuft. Es liegen keine Zugeständnisse vor, dies in einem Zeitraum mit vorgegebenem Endtermin abzuschließen.

Zu den betrieblichen Aspekten wiederum liegen auf Seite des angedachten Betreibers erste Erfahrungen mit einem bereits kundenseitig buchbaren Container-Basisdienst vor. Es ist geplant, den zukünftigen SouvAP-Betrieb in einem Kooperationsprojekt mit der Bundeswehr-Informatik GmbH als Bündel von Betriebsprozessen aufzubereiten derart, dass eine Art Betreiber-übergreifender Betriebsstandard für den SouvAP dokumentiert ist. Auch die automatisierte Nutzbarmachung von Artefakten ist bereits in grober Annäherung an die Zielsetzung „Continuous Delivery“ Gegenstand des Tagesgeschäfts, und zwar über die intern bereitstehende Zentrale Continuous-Delivery-Infrastruktur ZCDI. Aktuell erörtert Dataport den anstehenden Migrationsbedarf, mit dem die ZCDI „DVC-konform“ transformiert werden kann.

Um die Continuous Delivery Prozesse für die unterschiedlichen Betreiber perspektivisch in der Domäne Security zu entlasten und zu unterstützen erscheint eine zentrale, operative Unterstützung des ZenDiS durch das BSI nach dem EfA Prinzip erstrebenswert und effizient.

11.4 Risiken

Aus der Sicht der Architektur sind 2 Gruppen von Risiken zu diskutieren:

• Risiken aufgrund des Ist-Stands bzw. seiner Nutzung und
• Risiken aufgrund wünschenswerter bzw. erforderlicher Nacharbeiten.

11.4.1 Risiken zum Ist-Stand

Die Transformation wurde auf einen Probebetrieb hin zugeschnitten. Der mit Projektende erreichte Ist-Stand ist durch folgende Sachstände geprägt:

• Die Sicherungsmaßnahmen gemäß Projektauftrag (verpflichtende Konformität zu C5 und BSI IT-Grundschutz) sowie die im Architekturkonzept benannten Ergänzungen (Docker Best Practices, NIST SP 800-190) sind in der Informationssystemarchitektur und in der Infrastrukturarchitektur nicht vollständig umgesetzt.
• Die Containerisierung der SouvAP-Module ist mit „Container-ready“ zu bewerten.
• Die Pflege der auf Open CoDE bereitgestellten Artefakte ist derzeit ungeklärt.
• Die Prozesskette ab Ablage von Artefakten auf Open CoDE ist nicht ausformuliert.
• Die für den Probebetrieb benötigte technische Infrastruktur wurde bei einem Partner angemietet.
• Die Ausarbeitungen standardisierter Betriebskonzepte sowie belastbarer Dienstgütevereinbarungen sind nicht abgeschlossen.
• Die barrierefreie Bedienung ist gemäß vorhandener Prüfprotokolle nicht vollständig konform zu den Anforderungen der Zielvorgaben.
• Die Prüfung auf ein einheitliches Bedienkonzept hat offene Punkte aufgedeckt, die über den Gesamtverbund der SouvAP-Module noch zu harmonisieren sind.
• Die medienbruchfreie Interoperabilität – die Anforderung resultiert aus Nr. 10 der Eckpunkte zum Programm „Digitale Verwaltung 2020“1 – wurde im Projekt vornehmlich als Anforderung an Interoperabilität mit bereits vorhandenen Dokumentenformaten behandelt. Eine Bewertung von medienbruchfreier und effizienter elektronischer Abwicklung von Verwaltungsleistungen mit dem SouvAP als Ganzes ist ausstehend. Die in der Aufzählung genannten Sachstände lassen sich trennscharf in Handlungsfelder gruppieren, die einerseits als Aufgabenstellungen an die Software-Lieferanten sowie die Plattformbetreiber zu verstehen sind und andererseits Auswirkungen auf die gewünschte Akzeptanz seitens der potenziellen Nutzer entfalten dürften. Der Themenkreis Security ist dabei zu unterteilen in Aufgaben, die auf Seite der Software Lieferanten zu bewältigen sind und Maßnahmen, die die Plattform-Betreiber in der technischen Infrastruktur und deren Betrieb einziehen müssen. Aus Sicht der Architektur sind dazu Abstimmungen zwischen den Software-Lieferanten und den Plattform-Betreibern erforderlich.

11.4.1.1 Risikofeld Software

Der erreichte Reifegrad der SouvAP-Module betreffend der Containerisierung lässt sich bezüglich der Anforderungen an die DVS nur unscharf bewerten, da letztere zum Projektende weiterhin den Status „in der Bearbeitung“ hat. Die bisher bekannten DVS-Anforderungen an die Containerisierung der Software sind soweit wie möglich umgesetzt.

Die vollständige Segmentierung von Anwendungen in Frontend-, Backend- und Datenbank-Schicht wurde als langfristige Aufgabe eingestuft. Dies ist im Zuge der Weiterentwicklung der Fachanwendungen zu leisten. Da moderne Anwendungen etwa benötigte Datenbanken schon lange als eigenständigen Service neben der Fachanwendung nutzen und alle davon betroffenen SouvAP-Module diese Aufbauform nutzen, ist das diesbezügliche Risiko einer nicht DVS-konformen Umsetzung mit „gering“ zu bewerten. Es bleibt dennoch der Bedarf an erheblicher Überarbeitung der SouvAP-Module, um das Fernziel „Container-nativ“ erreichen zu können.

Die bisher durchgeführten Grundschutzchecks bescheinigen einigen SouvAP-Modulen in einem ausgeprägten Informationsverbund nach ISO 27001 auf der Basis von BSI-IT-Grundschutz zertifizierbar zu sein. Diesen Status wird Cryptpad laut Einschätzung seines Herstellers bis zum Projektende nicht erreichen. Element, Nordeck, OpenProject, Open-Xchange und Univention haben zu den erkannten Abweichungen von den Zielvorgaben Umsetzungspläne erzeugt. Eine Abschließende Bewertung der SouvAP-Module von diesen Herstellern ist ausstehend.

Der Umgang mit Sicherheitslücken ist derzeit ungeklärt. Als Ausweg aus erkannten Sicherheitsvorfällen bleibt vermutlich mehrheitlich nur eine Untersagung der Nutzung davon betroffener SouvAP-Module, was einer nicht mehr gegebenen Verfügbarkeit gleichkommt. Das Sicherheitsrisiko für den Betrieb von SouvAP-Modulen scheint unter diesen Rahmenbedingungen nicht abschätzbar, ist aber mindestens mit „hoch“ zu bewerten.

11.4.1.2 Risikofeld Betriebsplattform

Die Anforderung an die Separierung des Fachanwendungsbetriebs entsprechend ihrem Schutzbedarf über die technische Bereitstellung der Zugangspunkte via DMZ, Intranet und abgeschirmtes Netzsegment gelingt über voneinander isolierte Kubernetes-Cluster in eigenständigen Netzsegmenten. Das Risiko, diese Anforderung nicht erfüllen zu können, ist mit „gering“ zu bewerten.

Mit der Entscheidung, für den Probebetrieb eine Kubernetes-Infrastruktur bei einem C5-testierten und BSI-IT-Grundschutz-zertifizierten Anlagenbetreiber anzumieten, wurde ein sicherer Plattform-Betrieb ermöglicht. Es bleibt aber die Frage, ob der Betrieb von Software mit Schutzbedarf hoch auf einer fremdgesteuerten Kubernetes-Control-Plane nebst Middleware wie Lastverteiler konform zu BSI-IT-Grundschutz gelingt. Wenn die Kubernetes Plattform selbst nicht für SB-hoch zertifiziert ist, dann lautet die Antwort zweifelsfrei „Nein“.

Die Architektur zum SouvAP bewertet das Risiko für den produktiven Einsatz von SouvAP-Modulen für Verwaltungsaufgaben mit geringem bzw. normalem Schutzbedarf (SB-normal) mit hoch. Das Risiko für den produktiven Einsatz von SouvAP-Modulen für Verwaltungsaufgaben mit hohem Schutzbedarf (SB-hoch) bewertet die Architektur mit „kritisch“. Hierfür wird die bisher ungeklärte Verortung der Softwarepflege der auf Open CoDE abgelegten Artefakte verantwortlich gemacht. Solange diese Rolle nicht besetzt ist, ist die Behebung etwa bekanntwerdender Fehler ungeklärt. Dies wird als erhebliche Beeinträchtigung der funktionellen Integrität der SouvAP-Module eingestuft.

11.4.1.3 Risikofeld Nutzerakzeptanz

Die drei Kriterien barrierefreie Bedienung, einheitliches Bedienkonzept und medienbruchfreie Interoperabilität, stellen zwar nicht die Zulassung des Ist-Stands zum SouvAP für produktiven Betrieb in Frage, beeinflussen aber den erwarteten Geschäftsnutzen. Dafür zeichnen erhöhte Gefahren für geringe Akzeptanz des SouvAP verantwortlich, die über Erschwernisse bei der Bedienung begründbar sind. Die anwenderseitige Reaktion auf diesen Sachverhalt fällt erwartungsgemäß subjektiv aus, kann aber in eine komplette Ablehnung des SouvAP münden. Das Risiko, den Geschäftsnutzen und insbesondere die darin erwarteten betriebswirtschaftlichen Ziele nicht zu erreichen, muss daher mit „hoch“ bewertet werden.

Die Architektur hat empfohlen, der Gefahr der Ablehnung frühzeitig mit Aufklärungsarbeit zu begegnen und auf den SouvAP zugeschnittene Schulungsmaterialien und -programme aufzubereiten. Während der Transformation wurde dieser Bereich beobachtet und es wurde bei den Herstellern regelmäßig eine Selbsteinschätzung abgerufen, welchen Fertigstellungsgrad sie zu den Arbeitspaketen Anwender-Handbuch, Administrator-Handbuch, Quick-Start-Guide, Materialien für ein Selbststudium, Trainingskonzepte sowie Nachschlagewerke erreicht hat. Eine qualitative Prüfung der Ergebnisse ist zwar noch ausstehend, der Stand der Dokumentation scheint jedoch eine vielversprechende Grundlage für etwaige Ausbildungsvorhaben zu bilden. Das Risiko, den Ausbildungsbedarf nicht bedienen zu können, schätzt die Architektur daher auf gering.

11.4.1.4 Fazit

Die nachstehende Tabelle fasst die zuvor herausgearbeiteten Risiken zusammen.

xxx

11.4.2 Risiken zur Zielerreichung

Im vorhergehenden Kapitel wurde über eine Risikoermittlung die Softwarequalität, die Betreibbarkeit und die Nutzungsrisiken zum Transformationsergebnis beleuchtet. Das Resultat fällt auf den ersten Blick enttäuschend aus, da die Architektur den gesicherten und den wirtschaftlich erfolgreichen produktiven Betrieb des SouvAP in seinem Zustand zum Projektende mit hochgradig riskant bewertet hat.

Andererseits hat die Architekturarbeit aber auch die Stellschrauben identifiziert, die dem SouvAP zur Produktionsreife verhelfen sollen. Die Ergebnisse zum Ist-Stand konkretisieren die dominierenden Schmerzpunkte. Falls es gelingt, diese über Nachbesserungen zu minimieren, fallen die Betriebsrisiken. Ob damit auch das Risiko einer geschätzt schwachen Nutzerakzeptanz fällt, kann vermutlich erst der produktive Betrieb beweisen.

11.4.2.1 Reduktion der Software-Risiken

Die in Kapitel 5.1.1 diskutierten Ursachen für Risiken sind nach Einschätzung der Architektur über die Maßnahmen

• Steigerung der Reifegrade zu den Themen medienbruchfreie Interoperabilität, barrierefreie Bedienung und einheitliches Betriebskonzept,
• Modernisierung der Software hin zu Container-nativ und
• fortlaufende Softwarepflege erreichbar. Dazu sind die folgenden zwei Rahmenbedingungen zu befriedigen:
• Es ist qualifiziertes Personal verfügbar und
• die erforderlichen Personalkapazitäten und Sachmittel sind finanzierbar.

Das Risiko, geeignetes Fachpersonal für die Weiterentwicklung und die Pflege der Software zu finden, stuft die Architektur derzeit pauschal mit „gering“ ein. Die Erfahrungen aus der Transformation haben gezeigt, dass mindestens die am Projekt beteiligten Hersteller über die fachlichen Voraussetzungen verfügen. Es ist davon auszugehen, dass die Hersteller außerdem über ausreichende Kapazitäten entsprechend dem Bedarf verfügen bzw. diese bei Bedarf rekrutieren können. Eine Bewertung der Alternativen im freien Markt wird hier nicht vorgenommen, um eine Diskussion über Fachkräftemangel zu vermeiden.

Die Frage nach der Finanzierbarkeit ist aktuell ungeklärt. Zunächst müsste ein Kostenrahmen identifiziert werden und der setzt einen Wettbewerbsprozess voraus, in dem ein Bieter-Gremium den Finanzierungsbedarf erörtert. Das Ergebnis wäre immerhin ein Baustein für eine Kostenstruktur, die für die Ermittlung von Nutzungsgebühren dringen benötigt wird. Aktuell sind aber keine belastbaren Zahlen zur Finanzierbarkeit verfügbar und deshalb schätzt die Architektur das diesbezügliche Risiko konservativ mit „hoch“ ein.

11.4.2.2 Reduktion der Betriebsrisiken

Die Betriebsrisiken zum Ist-Stand nach der Transformation resultieren hauptsächlich aus der ungeklärten Zuständigkeit für die Pflege der auf Open CoDE abgelegten Artefakte. Der vorhergehende Abschnitt hat dazu bereits Gegenmaßnahmen diskutiert und analysiert, aus welchen Gründen diese ins Leere laufen können.

Mit der Entscheidung, die Betriebsplattform bei einem für C5 testierten und für ISO 27001 auf der Basis von BSI-IT-Grundschutz zertifizierten Unternehmen als Kubernetes-as-a-Service anzumieten, sind die Voraussetzungen für einen sicheren Betrieb von Verwaltungsfachanwendungen auch Ebenen-übergreifend für einen normalen Schutzbedarf gelegt. Für Schutzbedarf hoch und für die zukünftig geplante Verarbeitung von Verschlusssachen sollte aus Sicht der Architektur der Softwarebetreiber den Plattformbetrieb vollständig in Eigenregie verantworten. Es bleibt abzuwarten, ob und, wenn ja, wie die DVS-Umsetzung hierzu Stellung bezieht.

Ein Hinweis noch auf die Maßnahmen zur Sicherung des Informationsverbunds: Die Architektur sieht aufgrund des Studiums aktueller Empfehlungen zur Absicherung von Container-Services erheblichen Bedarf, Schutzmaßnahmen auf allen Ebenen einer Kubernetes-Plattform (Cloud, Cluster, Container, Code) einzuziehen. Der identifizierte Maßnahmenkatalog geht weit über die aktuell im BSI-IT-Grundschutz zusammengetragenen Basis- und Standard-Maßnahmen zur Härtung von Containern bzw. Kubernetes hinaus.

In der Summe bestehen die Empfehlungen zur Reduktion der Betriebsrisiken also in der Zusammenlegung von Softwarebetreiber und Plattformbetreiber sowie in der verstärkten Investition in Container-spezifische Härtungen. Dafür bedarf es analog der Reduktion der Software-Risiken qualifizierten Personals sowie die Finanzierbarkeit der benötigten Personalkapazitäten und Sachmittel.

Der Plattform- und Softwarebetrieb ist als reguläres Tagesgeschäft der darauf spezialisierten Dienstleister einzustufen. Die zu erwartenden Kosten für Personal und Sachmittel für den Betrieb sollten also sehr treffsicher abschätzbar sein und diese können direkt in die Ermittlung von Nutzungsgebühren einfließen. Es liegt in der Verantwortung des Betreibers, die Kostenstrukturen marktgerecht zu halten. Gelingt dies, dann gelingt auch eine für potenzielle Kunden attraktive Preisgestaltung. Das Umsetzungsrisiko wird hier mit „gering“ bewertet.

Eine Erweiterung der Security-Services um zusätzliche Härtungsmaßnahmen ist aus Sicht der Architektur als evolutionärer Prozess zu einzustufen, der im Zuge regelmäßiger Weiterentwicklung und Qualitätsverbesserung umzusetzen ist. Das Umsetzungsrisiko wird hier ebenfalls mit „gering“ bewertet.

11.4.2.3 Reduktion der Nutzungsrisiken

Nutzungsrisiken wurden im bisherigen Verlauf vorwiegend über Akzeptanzprobleme erklärt. Diese können ihre Ursachen z.B. in Berührungsängsten mit neuen Werkzeugen, unerwünschter Umstellung nach Werkzeugwechsel oder unzureichendem Vertrauen in Datenschutz haben.

Vorliegende Erfahrungen aus der bereits erfolgten Marktbegehung des SouvAP-Ausgangsprodukts dPhoenixSuite haben die soeben aufgezählten Hindernisse bestätigt: Schüler und Studenten hatten quasi von Beginn an hohe Akzeptanz in der Nutzung der Werkzeuge des Cloud-Servicepakets. Berührungsängste konnten mit gezielten Aufklärungs- und Marketingmaßnahmen deutlich reduziert werden, und zwar über alle Zielgruppen. Älteren Fachkräften ihre gewohnten Werkzeuge auszutauschen traf deutlich weniger auf Akzeptanz.

Die Herausforderung war nun, zu identifizieren, worin die unterschiedliche Akzeptanz begründet ist. Personen ohne Vorkenntnisse haben durchweg keine Akzeptanzprobleme gezeigt. Personen, die sich selbst als flexibel, neugierig und offen für Neues einstufen, haben allenfalls geringe Widerstände beim Werkzeugwechsel gezeigt. Als Ursache für eher geringe Wechselbereitschaft wurden Berührungsängste und Misstrauen identifiziert.

Maßnahmen zur Reduktion von Nutzungsrisiken müssen daher zielgruppengerecht vorbereitet und umgesetzt werden. Im Gegensatz zu den zuvor aufbereiteten Maßnahmen zur Reduktion von Software- bzw. Betriebsrisiken sind diese in zwei grundsätzlich verschiedene Gruppen zu gliedern:

• Maßnahmen vor der Einführung des SouvAP und
• Maßnahmen begleitend zur Nutzung des SouvAP.

Die Maßnahmen sollen jeweils Aufklärungen und Schulungen umfassen. Maßnahmen vor der Einführung des SouvAP sind vermutlich überwiegend im Marketing zu verorten. Sie erzeugen also Kosten, für die keine direkte Gegenfinanzierung gelingt. Maßnahmen begleitend zur Nutzung des SouvAP hingegen können teils über Nutzungsentgelte, teils über kostenpflichte Fortbildungen refinanziert werden. In beiden Fällen schätzt die Architektur die Risiken betreffend Umsetzbarkeit und Erfolg solcher Maßnahmen auf gering.

5.2.4 Fazit Zusammenfassend führt die nachstehende Tabelle die Risiken zusammen, die einen Ausbau des Ist-Stands hin zur Zielerreichung behindern können.

xxx

11.5 Fortlaufende Bewertung der Transformationsergebnisse

Die Architekturvision hat eine Prognose erstellt, welche Unternehmensziele die Transformation in welchen Maßen beeinflussen wird. Zum erreichten Ist-Stand nach der Transformation sind nach einer Erprobungsphase Bewertungen der Transformationsergebnisse zu erstellen und diese sind gegen die Anfangs erzeugten Erwartungen zu spiegeln.

Es ist einzuplanen, dass die Erprobungsphase mehrere Zyklen umfassen wird, in denen die unterschiedlich vorbereiteten Nutzergruppen jeweils Lernkurven durchlaufen werden. Dabei wird erwartet, dass die Nutzergruppen keine einheitlichen Fortschritte erzielen werden. Außerdem wird erwartet, dass Bewertungen der erreichten Reifegrade (bezogen auf die Unternehmensziele) mit fortschreitender Dauer des Probebetriebs Schwankungen unterworfen sind.

Diese Entwicklungen sollen in Trendanalysen einfließen. Daraus gewonnene Ergebnisse, insbesondere Abweichungen von der Zielerwartung nach unten, sollen besondere Beachtung finden und ggf. einen Handlungsbedarf für Nachsteuerungen veranlassen.

Diese Aktivitäten sind als fortlaufender Governanceprozess außerhalb der Architekturarbeit zu betreiben. Die Architektur empfiehlt, das Vorgehen zu schematisieren und die Arbeitsergebnisse regelmäßig der Unternehmenssteuerung zur Verfügung zu stellen. Die Ergebnisse sollten mit schnell wahrnehmbaren und unmissverständlichen Grafiken aufbereitet sein, eine schriftliche Interpretation der so aufbereiteten Fakten enthalten und idealerweise auch Handlungsempfehlungen mit ergänzender Darstellung von erwarteten Vor- und Nachteilen pro Entscheidungsoption enthalten.

11.6 Aufbereitung von Änderungsanforderungen

Im zuvor genannten Schritt erkannter Anpassungsbedarf ist als Eingabeinformation für einen formalisierten Änderungsprozess aufzubereiten. Dazu ist zunächst die Ausgangslage darzustellen, in der typischerweise Abweichungen von den erwarteten unternehmerischen Zielen konkretisiert werden.

Die Herausforderung besteht dann darin, eine Ursache für die Abweichungen zu identifizieren und darzustellen, welche Maßnahmen eine Korrektur der Abweichungen erwarten lassen. Ein so generiertes Maßnahmenbündel ist im nächsten Schritt als Anforderungskatalog aufzubereiten.

In diesem Stadium liegen nun Aussagen zu Ursachen für Abweichungen vom erwarteten unternehmerischen Ziel vor und es sind Maßnahmen zusammengestellt, die eine Verbesserung des Ist-Stands versprechen. Es fehlt lediglich noch eine Einschätzung der Auswirkungen der zusammengetragenen Änderungsanforderungen, also eine Zusammenstellung von Vor- und Nachteilen, die aufgrund der Umsetzung einer oder mehrerer Änderungen erwartet werden. Es ist auch zulässig, zu jeder erkannten Ursache Varianten von Änderungsanforderungen zu entwickeln, die sich gegenseitig ausschließen.

11.7 Entscheidungsfindung zu Änderungsanträgen

TOGAF empfiehlt, die zuvor erzeugten qualifizierten Änderungsanforderungen an das Architekturboard zu richten und dort eine Umsetzungsentscheidung abzurufen. Mit Ende des Projekts wird das Architekturboard zum SouvAP aufgelöst, sodass dort perspektivisch keine Entscheidungsarbeit mehr geleistet werden kann.

Vor diesem Hintergrund empfiehlt die Architektur, Änderungsvorhaben zunächst unter den Anspruchsgruppen der jeweiligen Rollengruppen Software-Lieferanten, Plattform-/Software-Betreiber und Nutzer zu beraten. Betrifft das Änderungsvorhaben lediglich eine Rollengruppe, dann ist zunächst unter den Anspruchsgruppen dieser Rollengruppe zu bewerten, ob das oder die Änderungsvorhaben Auswirkungen auf die übrigen Rollengruppen entfalten können. Für diesen Fall wären Vertreter der betroffenen Rollengruppen hinzuzuziehen.

Zwei Beispiele dazu:

• Der Plattform-/Softwarebetreiber hat eine Schwäche in seinen Sicherheitsmaßnahmen aufgedeckt und diese soll durch eine zusätzliche Maßnahme im Netzwerk abgefedert werden. Die Umsetzung der Maßnahme erfordert keine Anpassungen auf Seiten der SouvAP-Module. Für die Nutzer des SouvAP ist die Anpassung ohne spürbare Auswirkungen. Die Änderung kann auf der Seite des Plattform-/Software-Betreibers entschieden werden und es sind keine Beteiligungen von Vertretern der übrigen Rollengruppen benötigt.
• Der Software-Lieferant möchte eine überarbeitete Version eines SouvAP-Moduls in die Produktion überführen. Die erforderlichen Anpassungen auf der Seite des Plattform-/Softwarebetreibers gelingen über den bereits definierten Prozess für Softwarepflege. Die überarbeitete Version enthält neue Funktionen und bereits vorhandene Funktionen sind abweichend zu bedienen. Die Rollengruppe Nutzer muss vorab über die anstehenden Änderungen informiert werden. Idealerweise kann für eine Übergangsphase ein Parallelbetrieb der alten und der neuen Version unterhalten werden. Dies ist mit der Rollengruppe Plattform-/Software-Betreiber abzustimmen.

11.8 Implementierung von Änderungen

Aus der Sicht von TOGAF begründen Entscheidungen zu Änderungen eine neue Iteration des TOGAF-Architekturentwicklungszyklus. Anders als in der ersten Iteration kann das Vorhaben bereits vorhandene Ausarbeitungen wiederverwenden. Je nach Grad der Änderung können die Nacharbeiten sehr kurz oder sehr umfangreich ausfallen. Die zuvor illustrierten Beispiele lassen vermutlich erahnen, was bei einem erneuten Durchlauf an Anpassungen zur vorhandenen Dokumentation erforderlich ist:

• Das Anforderungs-Repository ist um die neuen Anforderungen zu ergänzen.
• Die betroffenen Architekturdomänen sind zu überarbeiten.
• Es ist eine auf die Änderung zugeschnittene Roadmap zu entwickeln.
• Es sind Umsetzungsrisiken zu ermitteln und zu bewerten.
• Die Umsetzung ist zu steuern.
• Die neuen Leistungsmerkmale sind in die fortlaufende Bewertung der Transformationsergebnisse einzubeziehen.
• Neue Änderungsanforderungen können Änderungen an bereits erfolgten Änderungen begründen.

Die Liste erhebt keinen Anspruch auf Vollständigkeit. Es dürfte aber erkennbar sein, dass der Aufwand nur bei signifikanten Änderungsvorhaben gerechtfertigt erscheint. Somit liegt es in der Verantwortung der Unternehmenssteuerung, die Freigabe für eine erneute Aufnahme einer TOGAF-konformen Architekturarbeit zu erteilen.

Nach dem Auslaufen des Projekts SouvAP hat die Architektur keine Zuständigkeit für Änderungen nach Projektende. Mit den hier vorgelegten Empfehlungen will die Architektur aber die Grundlagen geschaffen haben, auf deren Basis ein begründeter, nachvollziehbarer und bewerteter Umgang mit Änderungsanforderungen gesteuert werden kann.