die bank 08 // 2016

ó IT & KOMMUNIKATION

ó IT & KOMMUNIKATION über erlauben es tägliche Software-Updates, Sicherheits-Patches zeitnah bereitzustellen. Dementsprechend muss die gesamte IT agil werden. Und doch stehen Devops im Bankengeschäft zunächst noch große Hürden im Weg: ó 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 Back End. 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. ó Banken können ihre Kunden nicht den gleichen Experimenten aussetzen wie die meisten Internet-Start-ups. 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. ó 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. 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 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 macht Devops keinen Sinn, wenn zum Beispiel die Infrastruktur-Abteilung 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 76 diebank 08.2016

IT & KOMMUNIKATION ó Devops die Analyse stehen: In welchen Einsatzgebieten macht 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. Erfahrungen mit Devops Da die ersten Erfahrungen vorliegen, lassen sich bereits heute einige Aussagen über die wichtigsten Erfolgsfaktoren und generellen Trends treffen, wie die nachstehenden acht Erfahrungen mit Devops belegen: ó Die Gesamtbetriebskosten werden transparenter, da Design, Entwicklung und Betrieb von Software enger miteinander verzahnt werden und so einen ganzheitlicheren Blick ermöglichen. ó Die Bedeutung des 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. ó Die Änderungsfrequenz innerhalb der IT nimmt zu, ohne dass die Qualität leidet. ó 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. ó Devops sieht in jeder Branche mit ihren spezifischen Geschäftsmodellen immer anders aus. Entsprechende Anforderungsanalysen sind deshalb unabdingbar. ó 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. ó Dieser unabhängige Dritte muss in der Lage sein, die Ideen der externen Anbieter von Technologie und Prozessen in konkreten Business-Nutzen zu übersetzen. ó Stimmen 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. ó Autor: Prashant Kelker ist Director bei der ISG Information Services Group Germany in Frankfurt am Main. Das Abo für Risiko- Experten Print und online RISIKO MANAGER ist die führende deutsche Fachzeitschrift für Risikomanagement. Im Abo enthalten sind alle Printversionen sowie ein Premium-Login auf der Website. Die Printversion ab 2016 umfasst 10 Hefte pro Jahr. Der geschlossene Content-Bereich enthält sämtliche Ausgaben der Zeitschrift seit Heft 1 (2006) im digitalen Volltext. › › Sichern Sie sich ein Jahr lang die Fachzeitschrift RISIKO MANAGER für 411,95 €. * Jetzt bestellen unter: www.bank-verlag-shop.de * inkl. Versand und 08.2016 MwSt. diebank 77