Im Gespräch: Gerald Hofer, Geschäftsführer Operations der DB Systel GmbH
„Cloud ist ein Konzernziel“
Der IT-Dienstleister der Deutschen Bahn, die DB Systel GmbH, verlagert ihr Rechenzentrum in die Amazon-Cloud. Bei diesem ehrgeizigen Projekt stellte sich nicht etwa die technische Umstellung als größte Hürde heraus, sondern der Wandel bei den Einstellungen der Mitarbeiter.
iX: Welche Rolle spielt die DB Systel GmbH als hauseigener IT-Dienstleister für den Gesamtkonzern Deutsche Bahn?
Gerald Hofer: Die Deutsche Bahn hat über 300 000 Mitarbeiter, davon beschäftigen sich knapp 8000 mit IT. Davon sind etwa 3600 in der DB Systel beschäftigt. Damit sind wir eine zentrale Stelle in der Konzern-IT (ausgenommen davon ist die Leit- und Sicherungstechnik des DB-Streckennetzes). Wir gestalten die Digitalisierungsstrategie des Konzerns aktiv mit.
Neben einem konzernweiten CIO, der unabhängig von uns agiert, gibt es in den Konzerngesellschaften der DB (etwa im Fernverkehr, beim Logistikdienstleister Schenker, bei der britischen Arriva) eigene CIOs, die relativ frei in der Gestaltung ihrer Projekte sind. DB Systel ist gewissermaßen eine Supply-Organisation, die einzelnen CIOs mit ihren Gruppen sind die Demand-Organisationen.
Wie ging es mit dem Projekt Cloud-Umzug los?
Der Anlass war eine strategische Neupositionierung. Auf dem Markt sind heutzutage vor allem die klassischen IT-Serviceprovider unterwegs, wie IBM, HP Enterprise oder T-Systems. Und das waren wir von der DB Systel auch zu 100 Prozent für den Bahn-Konzern intern. Wir beobachten, dass seit einigen Jahren Themen wie Software as a Service (SaaS) vermehrt nachgefragt werden und – teilweise an uns vorbei – Einzug in den DB-Konzern finden. Das ist naheliegend: Wenn ich Software als Dienstleistung anderswo buchen kann, muss ich nicht mehr unbedingt mit der eigenen IT sprechen, schließe einfach einen Vertrag ab und greife übers Internet auf den Dienst zu.
Wir haben außerdem beobachtet, dass nach kurzer Zeit der Bedarf aufkommt, diese Services miteinander zu kombinieren. Es ist ja nicht wie bei einer Privatperson, die etwa Evernote als Service kauft und dann benutzt, sondern in einem Unternehmen hängen an jedem Dienst Workflows und andere übergreifende Zusammenhänge. Wenn Mitarbeiter drei unterschiedliche Tools ausgewählt haben und weiterhin im Projektmanagement-Tool zusammenarbeiten wollen, wird es schwierig.
Diese Erkenntnisse haben uns vor gut zwei Jahren zu der strategischen Neuausrichtung bewogen: Es gibt einen immer größeren Bedarf an SaaS, der teilweise ohne die Beteiligung von uns oder den eigenen IT-Abteilungen gestillt wird. Unsere neuen Hauptrollen verstehen wir so, dass wir alles, was es draußen am Markt an echten digitalen Innovationen gibt, für die Bahn verfügbar machen wollen. Viele Dinge haben wir in der Vergangenheit selbst erledigt – gemäß der Anspruchshaltung von Softwareentwicklern: Das Tool ist gut, aber wir können das selbst entwickeln. Und drei Jahre später ist das Tool dann fertig, wenn das Thema am Markt schon keine Rolle mehr spielt. Dieser Anspruchshaltung wollten wir mit der „Cloudifizierung“ gegensteuern. Die Möglichkeiten, die IT-Konzerne am Markt anbieten, sollen für die Bahn möglichst schnell verfügbar sein – egal ob Infrastructure, Platform oder Software as a Service. Das betrifft auch Dinge wie zum Beispiel Bezahldienste wie MANGOPAY oder ähnliche Ideen von Start-ups. Statt jeden Bezahldienst einzeln anzubieten, richten wir eine API ein, sodass unsere Kunden den Dienst nutzen können.
Sie sind also im Zuge der Cloud-Strategie mehr in die Moderatorenrolle hineingewachsen?
Wir verstehen uns nicht als IT-Polizei, aber nehmen Sie als Beispiel Amazon. Als Privatperson hinterlegen Sie dort Ihre Kreditkartendaten und nutzen die gebotenen Dienste. Im Business-Umfeld läuft es anders. Wir haben strenge Richtlinien einzuhalten, es gibt Compliance-Vorgaben, etwa keine Daten außerhalb Deutschlands zu lagern. Bei Amazon Web Services (AWS) kann man unterschiedliche Zonen und Rechenzentren wählen, und wir beschränken die Auswahl auf Rechenzentren in Deutschland, beispielsweise in Frankfurt. Über einen solchen Mechanismus stellen wir technologisch sicher, dass für jemanden, der bei der Bahn an einem Projekt programmiert, die Compliance eingehalten ist. Außerdem verbieten wir, dass gewisse Security-Features eigenmächtig ausgeschaltet werden. Weiterhin geben wir vor, dass man nur mit einem Netzkonzept programmiert.
Wie grenzen Sie Dienste ein? Gehen Sie auf spezielle Angebote ein, etwa Lambda?
Wir geben bei uns vor, welche Services nutzbar sind. Das macht bei uns ein CTO mit einer Gruppe von Architekten. Die Kriterien für so eine Entscheidung sind vor allem: Ergibt sich aus einer Nutzung ein Vendor-Lock-in? Binden wir die Bahn zu sehr an einen Dienst? Irgendein Lock-in haben Sie immer. Die Frage ist: Ist dieses Lock-in fundamental? Lambda etwa gibt es nur in der AWS-Cloud. Man hat einen riesigen Aufwand, um da wieder rauszukommen und in einer anderen Cloud (etwa Azure, Oracle, IBM) unterzukommen.
Wir haben festgestellt, dass etwa 90 Prozent der Services zwischen den verschiedenen Clouds identisch sind. Sie können dabei also jederzeit zwischen Google, Amazon oder IBM wechseln. Nur 5 bis 10 Prozent der Funktionen sind sehr spezifisch, und etwa die Hälfte davon bedeutet ein Vendor-Lock-in in der vollen Tiefe, aus dem Sie kaum wieder herauskommen. Wenn wir Architekturen bauen, nutzen wir deshalb nicht alle Dienste und kombinieren verschiedene Cloud-Angebote miteinander, um für uns das Optimum herauszuholen.
Inwiefern spielt die Frage nach der Sicherheit eine Rolle bei der Cloud-Entscheidung?
Uns geht es bei der Cloud nicht so sehr um die Security-Frage, wenn man Daten umziehen will. Bei der AWS-Cloud nutzen wir statt der vorhandenen Angebote eigene Security-Konzepte und eigene Verschlüsselung, auf die AWS keinen Zugriff hat. Die Logik bei allen Cloud-Providern ist ja, dass sie Ihnen sagen: Wir sind verantwortlich für die Sicherheit der Cloud. Und Sie, lieber Kunde, sind verantwortlich für die Sicherheit in der Cloud. Und wir legen natürlich größten Wert auf die Sicherheit innerhalb der Cloud und achten darauf, dass sie den geltenden Datenschutzbestimmungen entspricht und alles verschlüsselt ist. Es gibt nur wenige Daten, die wir langfristig nicht in die Cloud bringen können, etwa bestimmte Mitarbeiterdaten oder wichtige Vorstandsunterlagen.
War es eine Option, mit neuer Hardware im eigenen Rechenzentrum eine Private Cloud mit ähnlichen Dienstleistungen aufzubauen?
Es hat solche Überlegungen und Ansätze gegeben. Aber sie gingen meist in die Richtung, dass man die Amazon-Cloud im Haus nachbauen wollte. Die Flexibilität der Angebote am Markt erreichen Sie damit aber nicht – mit neuer Serverhardware hat man sich zunächst einmal für mindestens fünf Jahre festgelegt. Auf der Ebene der Netztechnik ist man sogar 10 bis 15 Jahre gebunden. Das sind riesige Investment-Zyklen, und wenn man sieht, mit welcher Geschwindigkeit IT und Digitalisierung mittlerweile ablaufen, dann sieht man, dass man bei sich zwar ein bestimmtes Angebot aufgebaut hat – aber was im DB-Konzern alles nachgefragt und gebraucht wird, können Sie damit nie abdecken. Deshalb sind wir in diese Mittlerrolle gegangen und haben gesagt: Wir machen das, was draußen am Markt existiert, für die DB verfügbar. Andererseits haben wir dabei darauf geachtet, nicht immer wieder dasselbe einzukaufen. Bieten die unterschiedlichen Clouds zu 90 Prozent dasselbe an, dann schauen wir uns die restlichen Funktionen an und prüfen, ob sie für irgendetwas einen Mehrwert bringen. Dann entscheiden wir, nur eine Public Cloud anzubinden, und verzichten auf die 10 Prozent Funktionen der restlichen Anbieter – wir müssen nicht alles anschließen, was es gibt. Gibt es Alternativen, legen wir zentral fest, was zur Nutzung freigeschaltet wird.
Welche Angebote haben Sie geprüft, und wie sind Sie in dieser Phase vorgegangen?
Im ersten Schritt haben wir uns auf Infrastruktur konzentriert und die Marktlage angeschaut, Funktionen und Flexibilität bei den führenden Anbietern verglichen. Dabei blieb zunächst AWS übrig. Natürlich sind Security und Compliance berücksichtigt worden, und wir haben unseren Plan der internen Compliance-Abteilung vorgelegt sowie unserer Aufsichtsbehörde in Berlin. Die haben Anforderungen gestellt, etwa an die Sicherheit: Die Daten in der Cloud müssen vollständig verschlüsselt sein, die Schlüssel müssen im Besitz der Bahn sein und nicht im Besitz des Cloud-Anbieters. Wir müssen außerdem sicherstellen, dass nur in Deutschland provisioniert wird.
Wie verlief der Projektstart, und wie ist der Cloud-Umzug im Unternehmen angenommen worden?
Es gab Tausende Begründungen, warum etwas in der Cloud nicht funktionieren kann. Da werden aber technische Gründe angeführt gegen etwas, das man emotional ablehnt. Wir haben daher ein Team gegründet und es autark (und gewissermaßen „undercover“) an einer Umsetzung arbeiten lassen. Diese Mitarbeiter haben einen radikalen Ansatz gewählt: Sie haben den Quellcode einer Anwendung genommen und ohne viel Planung einfach in die Cloud geworfen – und siehe da: Es hat funktioniert. Es wurden daraufhin in relativ kurzer Zeit etwa 50 Applikationen in die Cloud migriert. Zugegeben, es waren nur unkritische Anwendungen, etwa das Verzeichnis aller Bahnmitarbeiter mit persönlichen Angaben, Standort und Telefonnummer. Das war natürlich nicht unternehmenskritisch, aber es war ein Anfang.
Wir clustern die Anwendungen in Gruppen und entwickeln für die Gruppen unterschiedliche Vorgehensweisen, je nachdem wie schnell sie migrierbar sind. Die Migration verläuft für Softwareentwickler in einem Drei-Phasen-Modell. Die erste Phase heißt „Lift and Shift“: Sie übertragen die Applikation, wie sie ist, in die Cloud. In der zweiten Stufe optimiert man eine Anwendung über ihre Grenzen hinweg und nutzt die gemeinschaftliche Verwendung von Ressourcen: Wenn etwa jedes Verfahren für sich 50 TByte Storage alloziert, schalten wir solche Vorgänge zusammen und schaffen in der Cloud dadurch einen übergreifenden Nutzen. Das bringt aber noch nicht allzu viel.
Spannend wird es in der dritten Phase, in der die Anwendung an die Cloud angepasst wird. Wenn Sie in der ersten Phase die Anforderung haben: ein Server, 12 Cores, eine bestimmte Datenbank und so weiter – dann bildet man eins zu eins das, was physisch im Rechenzentrum steht, in der Cloud ab, zieht das Verfahren (die Anwendung) um, und meist läuft sie unter diesen Bedingungen weiter. Jedenfalls haben wir bis jetzt kaum ein Verfahren gefunden, das so nicht funktionieren würde. Das Ganze wäre aber sehr teuer und enthält auch kein Einsparpotenzial.
Anschließend muss man die Anwendung so einstellen, dass in der Nacht, wenn etwa nur noch fünf User zugreifen, von den 12 Cores 11 abgeschaltet werden. Das ist der enorme Aufwand der dritten Stufe: die Anwendung verbrauchsorientiert zu betreiben und damit Geld zu sparen. Denn das ist der Vorteil der Cloud: nur die benötigte Leistung im Sekunden- oder Minutentakt abzurufen und zu bezahlen.
Der Anteil der Anwendungen, die ohne Codeanpassungen „einfach“ liefen, war demnach relativ hoch?
Mit „Lift and Shift“ laufen viele Anwendungen in der Cloud, ohne dass die Software das mitbekommt. Probleme traten gelegentlich auf, wenn Konfigurationen der Netzumgebung fest in der Software integriert waren, was Nacharbeiten nötig machte. Aufwendig ist erst, die Anwendung Cloud-ready zu machen. In diesem Punkt hat die Bahn den Vorteil, dass das Geschäft zu großen Teilen von der Tageszeit abhängt – die Kunden fahren etwa zwischen 5 Uhr morgens und 23 Uhr abends Zug, nachts müssen Server nicht mit voller Leistung laufen. Das ist vielleicht anders bei einer Bank, die rund um die Uhr Rechenleistung beansprucht. Für uns mit diesem Anwendungsszenario ist die Cloud ein sehr interessantes Geschäftsmodell.
Von der Cloud haben Sie demnach nichts „gemerkt“, weder Netzstruktur noch -performance haben sich bemerkbar gemacht?
Nein, es gab sogar an vielen Stellen Performancesteigerungen. Das bereits erwähnte Verzeichnis mit 300 000 Mitarbeitern etwa ist wesentlich performanter geworden. Den Vorteil hat man bei nahezu allen Cloud-Anbietern, nicht nur bei AWS. Die haben große Netzkapazitäten und verlegen ihre Leitungen durch halb Deutschland – und haben ein Interesse daran, dass die Kunden maximales Tempo bekommen, was Sie als Unternehmen mit eigener Infrastruktur nur mühsam schaffen, etwa mit angemieteten Netzleitungen. Wir betreiben in Berlin ein Hauptrechenzentrum und in der Nähe noch ein sogenanntes Dunkel-Rechenzentrum für die Redundanz.
Hat der rückläufige Bedarf an RZ-Kapazität eine Rolle bei der Cloud-Entscheidung gespielt?
Ja, die Entscheidung, das eigene RZ aufzugeben, rührt auch daher, dass wir immer mehr Software und Infrastructure as a Service nutzen und damit die Rolle des eigenen RZ an Bedeutung verliert. Wir hatten immer weniger Server auf einer riesigen Fläche in Betrieb. Man kann das auch an den PUE-Werten [Power Usage Effectiveness, d. Red.] ablesen. Man misst ja damit Stromverbrauch, Effizienz und so weiter. Daran sehen wir bei uns seit Jahren eine Verschlechterung dieser Werte, obwohl wir alles auf dem neuesten Stand haben. Der Grund ist: Wir haben immer mehr freie Fläche und immer weniger Server, und wir wollten die Fläche nicht vermieten. Daher werden wir alles verkaufen und haben beschlossen, die 20 Prozent Kapazität für nicht migrierbare Altsysteme zu mieten – dafür müssen wir nicht selbst die gesamte Infrastruktur vorhalten. Außerdem wollten wir hochqualifizierte IT-Mitarbeiter nicht mit Standardtätigkeiten beschäftigen, sondern sie in anspruchsvollen Themenbereichen der Digitalisierung und den Kundenprojekten unterbringen.
In den 90er-Jahren hatte die Bahn über 30 Rechenzentren, die schließlich alle in das eine in Berlin konsolidiert wurden. Die meisten Dienste sind aus Redundanzgründen in das benachbarte RZ gespiegelt. Zu Hochzeiten hatten wir 12 000 produktive Server zuzüglich Entwicklungs- und Testsystemen. Im Zuge von Virtualisierung ist diese Zahl auf 6800 gesunken, jedoch bei verdreifachter Rechenleistung.
Sie wollen bis 2022 das eigene Rechenzentrum überflüssig machen. Wenn eine Abteilung danach ein Geschäftsmodell entwickelt, wird sie Infrastruktur aus der Cloud beziehen. Demnach verfolgen Sie nur vorübergehend eine Cloud-first-Strategie, im Grunde ist es eine Cloud-only-Strategie?
Das ist unser Ziel, aber wir müssen realistisch bleiben. Ich schließe nicht aus, dass es Ausnahmen geben wird, aber wenn man 20 unterschiedliche Modelle betreibt, verstehen das weder Kunden noch Mitarbeiter. Vor allem bei so einer großen Organisation wie der Bahn muss es Klarheit darüber geben, was gilt. Das heißt aber nicht, dass wir das Thema dogmatisch verfolgen – wenn es echte technologische Notwendigkeiten gibt, etwas anders zu machen, werden wir das auch tun. Wir legen dafür sehr hohe Hürden an: Wenn jemand sagt, das kann oder soll nicht in der Cloud laufen, schauen wir uns genau an, warum das technisch angeblich nicht geht.
Solche Anträge gibt es?
Ja. Von zehn Fällen, die dazu auf meinem Tisch landen, werden neun von unserem CTO und den Architekten abgelehnt. Da werden pseudotechnologische Debatten geführt, und wenn die Protagonisten an einem Tisch sitzen, können wir die Befürchtungen, die mit der Cloud zusammenhängen, wie etwa Arbeitsplatzabbau oder Lernkurven, schnell relativieren.
Ein Betrieb in der Cloud funktioniert völlig anders. Beim alten Modell des IT-Serviceproviders gab es viele Spezialisten. Und jeder hatte unverzichtbares Spezialisten-, wenn nicht sogar Herrschaftswissen erworben. Beim Cloud-Betrieb arbeiten alle vorrangig in Teams zusammen. Das wird oft vergessen: Beim Cloud-Umzug braucht man auch ein anderes Betriebsmodell. Die Umsetzung bei den Mitarbeitern ist vor allem ein kultureller Wandel. Schafft man es, dass viele Spezialisten sich freiwillig in ein Team von Generalisten überführen lassen, steigert das die Arbeitsproduktivität enorm. Das war und ist für manche Mitarbeiter ein Umdenkprozess. Vom Anfang bis zum Ende eines Projekts wird gemeinsam ein wirkliches Kundenproblem gelöst, und das schafft eine ganz andere Zufriedenheit.
Die technologische Seite eines Cloud-Umzugs ist relativ einfach zu handhaben. Die größere Arbeit besteht darin, den Wandel in der Einstellung dazu in der gesamten Belegschaft herbeizuführen und aus Spezialisten generalisierte Teams zu formen – den Firewall-Spezialisten oder den Storage-Spezialisten oder den Datenbankadministrator gibt es dann so nicht mehr. Alle arbeiten integriert zusammen an einem Kundenprojekt, und jeder kann die Grundlagentätigkeiten des anderen übernehmen. Es halten neue Methoden Einzug, und die müssen trainiert werden. Bei der Anwendungsentwicklung hat man es eher mit Scrum-Methoden zu tun, beim Betrieb eher mit Kanban.
Man geht also bei der Cloud-basierten Teamarbeit spontan vor und nicht entlang klassischer, am Workflow orientierter Change-Prozesse?
Es kommt darauf an, wie sehr man seine Prozesse zerlegt. In ITIL beispielsweise steht nirgends, dass man für alles einen Change Request braucht – das haben wir ITler beim Umsetzen von ITIL daraus gemacht. Selbstverständlich haben wir bei der DB Systel ein Change-Management, allerdings nicht mehr in dieser Granularität. Wir setzen ein Team auf eine Aufgabe an, das wie in einer Blackbox arbeitet und sich Anforderungen gewissermaßen über den Schreibtisch zuruft: etwa Anwendung stoppen, Firewall einrichten. Das läuft also nicht mehr über den klassischen Workflow. Erst nach Abschluss der Arbeiten meldet das Team in unser Workflow-Tool zurück, dass der Kunde jetzt arbeiten kann. Das bedeutet nicht, dass Chaos ausbricht und es keine Dokumentations- und Mitteilungspflichten mehr gäbe. Fällt am Gesamtsystem etwas aus, muss man natürlich zurückverfolgen, wer zuletzt etwas geändert hat, denn das ist immer noch die häufigste Fehlerursache.
Gab es Rückschläge, die vermeidbar gewesen wären, und würden Sie einige Dinge heute anders angehen?
Uns war auch in der Geschäftsführung von Anfang an klar, dass die ersten Schritte dieses Projekts nicht planbar sind. Wir haben mit Annahmen gearbeitet, die schnell verifiziert oder verworfen wurden. Das Modell war also „Zwei Schritte vor, einer zurück“ – das nervt manchmal und unterscheidet sich stark vom sonstigen Vorgehen, bei dem man Entscheidungen trifft, weil man sich bei den Zielen sicher ist und auf eine exakte Umsetzung pocht. Das ging beim Cloud-Projekt nicht, es gibt dafür ja keine Blaupausen. Anhand der Rückmeldung der Mitarbeiter konnte man rasch sehen, ob etwas funktioniert hat. Man gibt eine Richtung vor, aber das Vorgehen ist eher experimentell. Man kann nicht vorhersehen, wie eine Organisation sich bei einem Cloud-Umzug verändert und wie rasch das alles abläuft.
So ein Wandel fordert Menschen heraus, die darauf fixiert sind, weiterhin ihre vertrauten Probleme zu lösen. Aber im Cloud-Betrieb läuft das anders: Es geht nicht mehr darum, Logfiles zu lesen und ein Serverproblem zu beheben, sondern der Businessprozess muss wieder laufen, weil der Endkunde etwa eine Fahrkarte kaufen will. Das ist vor allem eine Einstellungssache bei den Mitarbeitern. Wir haben weniger Schwierigkeiten mit der technischen Umsetzung – dafür finden wir immer schnell eine Lösung – als vielmehr damit, diese Haltungen zu verändern, bei den Mitarbeitern und auch bei den Kunden. Es gibt kaum technische Gründe dafür, dass irgendetwas in der Cloud nicht läuft, die Barrikaden sind oft allein in den Köpfen.
Ist Ihr Plan, bis 2022 80 Prozent der Anwendungen in der Cloud zu betreiben, eine Vorgabe?
Wir haben uns selbst darauf verpflichtet und haben auch das Okay der Konzernleitung. Es gibt zudem ein konzernweites IT-Programm, das die „Cloudifizierung“ allen IT-Abteilungen in gewissem Maß vorgibt. Es geht dabei nicht nur um Kostenersparnis, sondern die Cloud ist ein Konzernziel und Grundlage der Digitalisierung. Das ganze Projekt des Cloud-Umzugs kostet über die fünf Jahre einen hohen zweistelligen Millionenbetrag, wird aber dazu führen, dass ein dreistelliger Millionenbetrag pro Jahr eingespart wird, verglichen mit dem Zustand heute. Und dieses Ziel werden wir einhalten. (tiw)