Nach „Agile“ kommt „Devops“: Banken-IT auf den Spuren der Internetfirmen

Prashant Kelker, Director bei der ISG Information Services Group Germany: 

Image may be NSFW.
Clik here to view.Zumindest im Privatkundengeschäft wurde zuletzt immer wieder prognostiziert, dass die klassischen Filialbanken auf Dauer nicht mit den innovativen, internetbasierten Ideen und Lösungen der Fintechs mithalten könnten – zumal ihre über Jahrzehnte gewachsene Software-Entwicklung schnelle und kundenorientierte Lösungen nicht mehr hervorbringe. Doch übersieht diese Sichtweise wichtige Punkte. Denn die Banken-IT ist weiter, als viele denken.

Ein Exkurs in die Automobilindustrie zeigt, warum Banken die Konkurrenz von Internet-Companies wesentlich weniger zu fürchten haben als viele andere Branchen. Autoverkaufsportale wie Autoscout24 verfügen mittlerweile über viel mehr Informationen über sämtliche Fahrzeugmodelle und die Käufer als die Hersteller selbst: Daten über tatsächliche Marktpreise, Preistendenzen, Käufervorlieben, Ausstattungsmerkmale und vieles mehr. Dieser Schatz an „Big Data“-Informationen steht den Herstellern selbst nicht zur Verfügung, sodass sie diese für zusätzliche datengestützte Services rund um ihr eigentliches Produkt auch nicht nutzen können. Ähnliches gilt für den Entertainment- und Info-Bereich, in dem Apple und Google die Nase vorn haben, und nicht die Insellösungen der Autokonzerne.

Bei Banken hingegen stellt sich die Situation ganz anders dar, denn 80 Prozent des Bankgeschäfts sind letztlich Transaktionen. Und diese laufen über Hintergrundsysteme und nicht etwa über die Schirme von Smartphones oder Tablets. Das Gros der Daten verbleibt also bei den Banken, während die Erstellung mobiler Apps keine große Herausforderung mehr ist. Auch Finanzkonzerne stellen diese mittlerweile innerhalb weniger Wochen auf die Beine.

Fintechs gehen in Banken auf

Derzeit sind zwei Strategien im Bankenumfeld zu beobachten: Die einen Institute versuchen Paypal & Co. das Wasser über eigene Easy-to-use-Angebote in ihren Online-Kanälen abzugraben. Die anderen kaufen die zu den eigenen Geschäftsmodellen passenden Start-ups einfach auf, wie es jüngst mehrfach geschehen ist. Die Financial Times veröffentlichte jüngst sogar einen typischen Lebenszyklus von Fintechs, der mit Phase 8 wie folgt endet: „Das Fintech-Startup wird in die Organisation einer Bank eingegliedert. Innovationen finden keine mehr statt.“

Doch nicht nur auf Seiten der Daten (Big Data) üben Internet Companies Wettbewerbsdruck auf etablierte Großunternehmen aus, sondern auch über ihr (anderes) Vorgehen bei der Software-Entwicklung. Die jüngste Innovation in diesem Bereich ist „Devops“ (kurz für: Development & Operations). Das Vorgehen erweitert den Ansatz der agilen Software-Entwicklung um den Betrieb. Zwar brachte „Agile“ ein großes Plus an Schnelligkeit, Flexibilität und Kundenorientierung in die Software-Entwicklung. Doch ihre eigentliche Bewährungsprobe bestehen auch die agil entwickelten Software-Produkte erst, wenn sie in Produktion gehen und der Markt über ihre Akzeptanz entscheidet. Wenn dieses Feedback allerdings nur zwei- oder dreimal im Jahr erfolgt, ist die während der Entwicklung gewonnene Geschwindigkeit und Kundennähe schon wieder dahin. Diese Erkenntnis führte zum Entstehen des Devops-Ansatzes, der neben der Entwicklung auch den Betrieb „agilisiert“.

Software Updates jeden Tag

Devops zielt auf die radikale Verkürzung der Entwicklungszyklen: etwa ein Update jeden Tag. Kommt eine Funktion am Markt nicht an, kann sie so am Folgetag einfach wieder abgeschaltet werden. Umgekehrt lassen sich Produktideen Schritt für Schritt erweitern, wenn sie bei den Anwendern auf Begeisterung stoßen: von der Idee in die Produktion innerhalb von 24 Stunden und dies dann durchaus auch mehrmals täglich. Dass diese kurzen Zyklen möglich sind, zeigen zahlreiche Unternehmen wie zum Beispiel Google, Apple oder Amazon, die es zum Teil sogar auf mehrere Tausend Software Releases pro Tag bringen.

Wegen solcher Erfolgsgeschichten nimmt der Devops-Zug derzeit rasant Fahrt auf. Gestartet als Technologie, entwickelt sich Devops zu einer umfassend neuen Philosophie für die gesamte IT. Beispiel IT-Sicherheit: Was nützen agile Entwicklung und Betrieb, wenn die Sicherheitsrichtlinien noch dem altbekannten Wasserfallmodell folgen und sich Sicherheitslücken erst nach Wochen oder Monaten schließen lassen? Demgegenüber erlauben es tägliche Software Updates, Sicherheits-Patches zeitnah bereitzustellen. Dementsprechend muss die gesamte IT agil werden.

Doch stehen Devops im Bankengeschäft zunächst große Hürden im Weg:

1. Auf den ersten Blick widersprechen die Geschäftsprozesse von Banken dem Devops-Prinzip, denn 80 Prozent des Geschäfts bestehen wie bereits erwähnt aus Transaktionen im Backend. Zwar ist das Web zu einem wichtigen Kanal für das Online Banking und den Aktienhandel geworden. Doch sind die meisten Finanzsysteme weiterhin auf die Kommunikation zwischen einzelnen Bankensystemen und auf B2B-Transaktionen ausgelegt, die zudem noch standardisierten Nachrichtenprotokollen wie FIX (Financial Information eXchange) oder SWIFT folgen müssen. Eingriffe in diese Transaktionssysteme können nicht zu oft und nicht zu schnell erfolgen.
2. Banken können ihre Kunden nicht den gleichen Experimenten aussetzen wie die meisten Internet-Startups. Facebook kann es sich leisten, bestimmte Funktionen auszuprobieren und bei Nichtakzeptanz einfach wieder abzuschalten. Bei Kontenführung und Aktienhandel sind solche Experimente de facto nicht möglich.
3. Schließlich unterliegen Banken strikten Regularien wie zum Beispiel ISO 27001 oder dem Grundsatz, dass Entwickler keinen Zugang zu Produktionsdaten haben dürfen („segregation of duties“). Dies setzt der nach Devops angestrebten Integration von Entwicklung und Betrieb enge Grenzen.

Vorreiter in Sachen Devops

Trotz alledem gehört die Finanzwirtschaft zu jenen Branchen, in denen Devops bereits am weitesten verbreitet sind – vor allem im schnellen Business des Investment Bankings. Denn letztlich besteht eine Bank aus einem großen Stück Software. Bankengeschäft und Software lassen sich nicht getrennt voneinander betrachten, sodass sich Banken immer am Puls der Software-Industrie befinden. Wenn ihr Business Software ist, haben sie gar keine andere Wahl, als neuen Software-Trends zu folgen, sobald diese sich als zukunftsweisend erwiesen haben. Denn Wettbewerbsvorteile bei Banken basieren fast immer auf Innovationen bei IT und Software. Dies zeigt auch der Einzug agiler Methoden in die Entwicklungsabteilungen der Banken im Lauf der vergangenen 15 Jahre. Die Deutsche Bank etwa stellte bereits 2007 auf breiter Front auf Agile um. Heute existiert mit SAFe (Scaled Agile Framework) sogar ein unternehmensübergreifender De-facto-Standard für den Breiteneinsatz von Agile bei Banken.

Dank dieser Vertrautheit mit agilen Methoden fällt Devops bei Banken auf sehr fruchtbaren Boden, indem es nicht nur die Entwicklung, sondern nun auch den IT-Betrieb „agilisiert“. Dementsprechend lässt sich für den Stand heute folgende Regel ableiten: Je weiter agile Entwicklungsmethoden in einer Bank bereits verbreitet sind, umso mehr Devops-Projekte gibt es bereits, vor allem im Investment Banking und bei Online Services. Ein Großteil der Aufgaben liegt dabei in den Händen von externen Anbietern, die bislang fast ausschließlich nach Aufwand berechnen. Die beauftragenden Banken stehen hier derzeit vor allem vor der Aufgabe, Devops in Festpreisverträgen mit klaren Service Level Agreements abzubilden. Dies ist möglich, wie eine vereinfachte Beispielrechnung zeigt: Ein Projekt, das 100 neue Anwendungsfunktionen entwickeln soll, kann exemplarisch ein Paket bilden, innerhalb dessen zehn dieser Funktionen nach Komplexität und Entwicklungsaufwand (niedrig, mittel, hoch) analysiert und bewertet werden. Die Werte lassen sich auf alle anderen Zehnerpakete übertragen, sodass sich auch der benötigte Aufwand für alle 100 Funktionen vorab festlegen lässt. Auf diese Weise ist das Budget fest definiert, während sich die einzelnen Funktionspakete je nach Bedarf – agil – abarbeiten lassen.

Die Einführung von Devops besteht nicht nur aus der Einführung neuer Prozesse, sondern erfordert auch einen grundlegenden Umbau der generellen Software-Architektur. Wenn zum Beispiel die Investment-Banking-Systeme auf eine alte Datenbank zurückgreifen, reicht es nicht, agile Devops-Prozesse nur im Investment Banking einzuführen. Zusätzlich gilt es auch, die bereits bestehenden Schnittstellen neu zu definieren. Auch ergeben Devops keinen Sinn, wenn zum Beispiel die Infrastrukturabteilung sechs Monate benötigt, um einen neuen Server zu implementieren.

Vom Hype zur Realität

Wie bei allen anderen Hypes haben sich auch bei Devops in Windeseile zahlreiche Anbieter in Stellung gebracht, die Devops fast immer „as a service“ anbieten. So argumentieren Hardware-Hersteller damit, dass ihre Hardware-Lösungen Devops erst ermöglichen. Die Systemintegratoren betonen, dass sie bereits breite Erfahrung mit „Agile“ haben und deshalb prädestiniert für Devops seien. Und aus ihrer Sicht haben sie auch sicher alle Recht. Doch die Anbieter selbst sind nicht die derzeitige Herausforderung der Banken. Diese müssen erst einmal Fragen wie die folgenden beantworten: „Was bedeuten die Prinzipien von Devops für meine Organisation?“, „Was muss ich als erstes ändern?“ oder „Was meint eigentlich der Begriff ‚Gewerk‘ in der Devops-Welt?“. Erst wenn solche grundlegenden Fragen beantwortet sind, sollten die Unternehmen an die bereits bestehenden sowie neue Software-Partner denken und SLAs, Verträge sowie Preismodelle an Devops anpassen.

Denn ungeachtet all der Vorteile die Devops mit sich bringt, darf das Vorgehen nicht als Allheilmittel betrachtet werden. Vor dem Einsatz sollte natürlich auch bei Devops die Analyse stehen: In welchen Einsatzgebieten ergibt Devops grundsätzlich Sinn, in welchen nicht? Für eine extrem sicherheitskritische Transaktionssoftware wohl weniger, für eine mobile App hingegen mehr. Auch ist abzuschätzen, ob und wie weit die Implementierung von Devops zu einem positiven Return on Investment führt. Die Erfahrung zeigt, dass dieser bei innovativen Systemen wesentlich größer ausfällt als bei Bestandsanwendungen.

All diese Umstellungen funktionieren sicher auch besser, wenn Banken den Langfristnutzen im Blick behalten, den sie mit ihren Reformen erzielen. So wird die damit verbundene Transparenz auch operationale Risiken deutlicher machen. Mehr und mehr automatisieren sich Prozesse in Entwicklung und Vertrieb, sodass sich schnell die Frage stellt, ob auch die IT-Zulieferer für diese Automatisierung Verantwortung übernehmen sollen. Insofern stellt Devops fast das gesamte derzeitige IT-Sourcing-Konzept auf den Prüfstand. All dies mithilfe externer Sourcing-Berater neu zu sortieren und an den eigenen Geschäftszielen auszurichten, sollte deshalb am Beginn einer jeden Devops-Initiative stehen.

Acht Erfahrungen mit Devops

Da die ersten Erfahrungen vorliegen, lassen sich bereits heute einige Aussagen über die wichtigsten Erfolgsfaktoren und generellen Trends treffen:

1. Die Gesamtbetriebskosten werden transparenter, da Design, Entwicklung und Betrieb von Software enger miteinander verzahnt werden und so einen ganzheitlicheren Blick ermöglichen.
2. Die Bedeutung von „Technical Debt“ steigt. So werden Software-Anbieter nicht mehr nur für eine funktionale Software sorgen müssen, sondern auch für eine, die sich schnell, einfach und kostengünstig anpassen lässt.
3. Die Änderungsfrequenz innerhalb der IT nimmt zu, ohne dass die Qualität leidet.
4. Nicht jede Software ändert sich in der gleichen Geschwindigkeit. In größeren Banken wird es mehrere Hundert verschiedene „Software-Geschwindigkeiten“ geben, die entsprechend unterschiedlich gemanagt werden müssen. Es gibt nicht nur – wie zum Beispiel Gartner ausführt – eine schnelle und langsame IT, sondern unzählige Abstufungen.
5. Devops sieht in jeder Branche mit ihren spezifischen Geschäftsmodellen immer anders aus. Entsprechende Anforderungsanalysen sind deshalb unabdingbar.
6. Nicht nur die IT-Anbieter selbst sollten das Devops-Vorgehen eines Unternehmens definieren. Vielmehr benötigt es zusätzlich einen unabhängigen Dritten, der den gesamten Sourcing-Mix unter Devops-Gesichtspunkten im Blick behält. Nur so kann aus dem Hype auch Wirklichkeit werden.
7. Dieser unabhängige Dritte muss in der Lage sein, all das Sprechen der externen Anbieter von Technologie und Prozessen in konkreten Business-Nutzen zu übersetzen.
8. Stimmt der Provider-Mix und das zugrunde liegende Sourcing-Modell, müssen Unternehmen Devops-Experten und ihr Wissen nicht unbedingt komplett einkaufen, sondern können dies von ihren Dienstleistern beziehen. Wenn der erwartete Nutzen klar vereinbart ist, kann sich die Banken-IT auf die Rolle des Technologie-Brokers konzentrieren, anstatt ständig eigenes Know-how und neue Mitarbeiter aufbauen zu müssen.

Dieser Beitrag erschien auch in „die bank“ in der Ausgabe vom 29. Juli 2016.