BAIT-konform und agil im Banking

Mehr Agilität! Dies ist die größte Herausforderung, die sich den Banken aktuell stellt, um im Zeitalter von Fintechs, mobilem Banking und durchgängiger Digitaler Transformation am Markt bestehen zu können. Vor allem DevOps ist dafür ein passender Technologieansatz.

Continuous Delivery – jeden Tag ein neues Release

Amazon, Google, N26 oder Uber – diese Internetfirmen sind so erfolgreich, weil sie auf der einen Seite genau wissen, was sich Kunden wünschen und ihnen genau das bieten. Auf der anderen Seite ist es die Geschwindigkeit, mit der sie ihr Angebot anpassen. Sie ändern ihre Software jeden Tag mehrfach und das im laufenden Betrieb. Durch diese Flexibilität sind sie in der Lage, die Funktionalität ihres Angebotes umgehend an sich ändernde Rahmenbedingungen anzupassen. Sei es, um neue Ideen zu testen, auf Kundenwünsche einzugehen, neue Compliance-Vorgaben umzusetzen oder auftauchende Fehler zu reparieren. Anders ist ein Überleben in der Welt von Cloud und Mobile Computing auch nicht mehr möglich.
Zwar lassen sich die Geschäftsfelder von Internetfirmen und Banken nicht eins zu eins vergleichen, dennoch gibt es auffällige Parallelen. Ob man wie Google Milliarden Suchanfragen pro Tag beantwortet oder als Bank Millionen von Börsentransaktionen durchführt. Am Ende des Tages zählen Speed, Benutzerfreundlichkeit und Zuverlässigkeit. All das ist ohne maximale Skalierbarkeit und Continuous Delivery nicht möglich.

Auf neuen Wegen mit DevOps

Wie lassen sich hunderte Softwareänderungen in einer komplexen Umgebung testen, sicher ausrollen und bei Bedarf wieder rückgängig machen? Hier kommt DevOps ins Spiel. Die Kombination aus Softwareentwicklung (Development) und dem IT-Betrieb (Operations) beschreibt Maßnahmen, mit denen sich Bruchstellen zwischen Anwendungsentwicklung und IT-Betrieb überwinden und die genannten Herausforderungen meistern lassen.
DevOps ist jedoch kein fertiges Produkt, sondern eine Methode, welche die Zusammenarbeit von Softwareentwicklung und IT-Betrieb beschreibt. Jeder IT-Dienstleister, so auch Adacor, muss ein eigenes Vorgehen erarbeiten und anschließend seinen Tool-Baukasten mit Software füllen. Daraus folgt, dass am Ende DevOps bei jedem Kunden und in jedem Projekt anders aussieht.

Bremsklötze Legacy-IT und Compliance

Internetfirmen und FinTechs können technische Neuerungen und flexible Verfahren relativ einfach realisieren. Der Grund: Sie starten zumeist auf der „grünen Wiese“ und haben beim Thema IT keine Altlasten. Sie können ihre IT ohne Rücksicht auf bestehende Systeme perfekt an ihrem Produkt ausrichten und dabei die neueste Technologie nutzen. Der Alltag bei Banken sieht da leider anders aus. Sie kämpfen mit über Jahrzehnten gewachsenen IT-Infrastrukturen, komplexen Plattformen und komplizierten Schnittstellen-Architekturen.
Als wäre das nicht genug, unterliegen sie umfangreichen Compliance-Vorgaben. Der Platz reicht nicht, um alle aufzuführen, aber alleine die Ende 2017 von der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) eingeführten „Bankaufsichtliche Anforderungen an die IT“ (BAIT) machen deutlich, in welch komplexem Umfeld sich Banken mit ihrer IT bewegen. Die BAIT regeln unter anderem Themen wie IT-Sicherheit, Datensicherung und Anwendungsentwicklung. Will man in einem solchen Rahmen Continuous Delivery realisieren, führt an DevOps langfristig kein Weg vorbei. Der DevOps-Ansatz bietet die Basis für agile Weiterentwicklung, umfangreiche Sicherheit, Nachverfolgbarkeit, Einhaltung von Compliance und flexible Skalierbarkeit.

Herausforderung Continuous Delivery am Beispiel Mobile Banking

Ein typisches Beispiel verdeutlicht die Herausforderungen von Continuous Delivery und die Möglichkeiten, die DevOps in diesem Bereich ermöglicht. Eine Großbank bietet ihren Kunden weltweit eine mobile Banking-App, die mit dem zentral verwalteten Kernbankensystem kommuniziert. Der “Kern” der App ist in allen Ländern gleich, wird jedoch durch landesspezifische Module an die lokalen Gegebenheiten angepasst.

Neue Funktionen oder gesetzliche Vorgaben müssen täglich, Sicherheitsupdates teilweise stündlich weltweit ausgebracht werden. Auf der einen Seite müssen dafür die Apps auf den mobilen Endgeräten, auf der anderen Seite die Server in der jeweiligen Niederlassung aktualisiert werden. Hinzu kommt, dass je nach Zuspruch der Endkunden die Anzahl der verfügbaren Server in der jeweiligen Cloud hoch- oder runtergefahren werden muss. Ein derartig schnelles Entwicklungstempo kollidiert mit traditionellen Betriebskonzepten, die vorsehen, dass jedes Release manuell vom Betriebsteam auf einer Staging-Umgebung getestet wird und dann auf das Live-System ausgerollt wird. Bei einem Release pro Monat mag dies noch funktionieren, aber nicht bei täglichen oder stündlichen Updates.

BAIT-konform – die praktische Umsetzung

Soll in dem genannten Beispiel etwa eine neue Software auf allen Servern installiert werden, dann war bisher viel manuelles Arbeiten angesagt. Der Administrator musste die Software für jedes System anpassen, sich sukzessive auf allen diesen Systemen einloggen, die entsprechende Datei installieren, das System eventuell neu starten, kontrollieren ob alles läuft – und nicht vergessen, sich am Ende wieder auszuloggen.
Sämtliche Vorgänge müssen natürlich irgendwo protokolliert werden, damit andere Admins diese nachverfolgen können und sie BAIT-konform sind. Entweder erfolgt das über einen Gatekeeper, auf dem man sich einloggt und von dort aus auf die Systeme zugreift. Dieser protokolliert dann alles. Oder man macht es manuell und muss dann auch alle Änderungen per Hand dokumentieren. Klar sein dürfte, dass bei händischem Vorgehen – vor allem, wenn man es an hunderten Servern durchführen muss – neben Langeweile auch Fehler vorprogrammiert sind.
All das kann man abstrahieren und automatisieren, wenn man sich in einer DevOps-Welt bewegt. Durch den Einsatz von DevOps kommt man weg davon, sich mit einzelnen Systemen zu beschäftigen. Dazu erstellt man Templates, programmiert also Code, der am Ende das macht, was bisher der Admin per Hand in die Shell des Servers eingegeben hat. Im Template schreibt man auf, was auf den Systemen verändert werden soll. Sämtliche Änderungen an den Vorlagen werden revisionssicher dokumentiert – der Admin spielt nur noch diese Templates aus.
Vor dem Ausspielen kann man alles auf einem Staging-System aufspielen und dort automatisierte Security-Tests anstoßen. Hier kann man das in Code “gegossene” Security-Framework der Bank gegen das Staging laufen lassen und so automatisch feststellen, ob das geplante Vorgehen den Sicherheitsrichtlinien der Bank entspricht. Das deckt auch das Vulnerability Management ab. Wenn die Tests bestanden werden, erfolgt automatisch eine Rückmeldung an das Automatisierungstool. Adacor verwendet dafür die Open-Source-Software Ansible von Red Hat. Ansible ermöglicht das Lifecycle-Management von Apps durch Anwendungsverteilung, Netzwerkautomation, Konfigurationsmanagement und Workflow-Orchestrierung. Im Abschluss sorgt Ansible zusätzlich für die Ausspielung der Änderungen auf allen Servern.
Das bedeutet, der sonst sehr aufwändige Prozess wurde stark automatisiert und verschlankt. Im Idealfall hat der Admin dabei keinen direkten Zugriff mehr auf Server, Dateien oder personenbezogene Daten. Dann braucht er das, was er tut, nicht mehr manuell zu dokumentieren.

Spiel nach festen Regeln mit dem Playbook

Wie eingangs beschrieben, gleicht kein DevOps-Projekt dem anderen. Damit man das Rad nicht immer wieder neu erfinden muss, nutzt Adacor Playbooks. Das Know-how und die Ergebnisse der Kooperation von Systemadministratoren und Entwicklern werden in Ansible-Playbooks gebündelt. Ein Playbook beinhaltet alle Befehle und Parameter, um ein neues System, Release oder einen Service online stellen zu können. Mittlerweile existiert eine ganze Bibliothek von Playbooks, auf deren Basis die Bereitstellung von Services – wie zum Beispiel Webserver, Application Server oder Datenbankserver – vollständig automatisiert erfolgen kann.

Aufwand, Zeithorizont und Vorteile

Wie viel Manpower muss man bereitstellen und wie lange dauert es, ein Projekt mit DevOps zu automatisieren? Selbst wenn jedes Projekt einzigartig ist – Adacor hat bereits viele Cloud- und DevOps-Projekte für Finanzinstitute realisiert. Exemplarisch sei die GLS Bank genannt. Aus diesen Projekten lassen sich durchaus ein paar Kennzahlen ableiten.
Angenommen, eine Bank möchte ein bestehendes System von On-Premise in die Cloud verlagern und die Anwendungen anschließend automatisiert mittels DevOps pflegen. Bei einem solchen Projekt, das eine signifikante Größe hat, kann man davon ausgehen, dass für Bestandsaufnahme, Zielvorgaben, Strategieentwicklung Migrationsplanung und im Anschluss Transitions-Support (also die Begleitung des “Umzuges”) mindestens 90 Manntage für Beratung notwendig sind. Die komplette Umsetzung dauert dann zwischen drei und 12 Monaten.
Der Aufwand und die Kosten machen sich jedoch meist schnell bezahlt. Die wichtigsten Vorteile des DevOps-Ansatzes sind folgende:

• Skalierbarkeit: Neue Anwendungen können auf beliebig vielen Systemen automatisiert ausgebracht werden
• Diese Automatisierung erhöht Effektivität und Effizienz
• Ein Rollback ist genauso möglich wie der Rollout
• Kein direkter Zugang zu den IT-Ressourcen notwendig
• Compliance – 100%ige Nachverfolgbarkeit wer, wann, was, wo gemacht hat
• Keine Sackgasse bei veränderten Anforderungen im Projektverlauf
• Kein Vendor-Lock-in durch Nutzung von Open-Source-Technologien
• Stabilere Anwendungen, effizientere Prozesse und mehr Freiraum für Innovation
• Schnellere Umsetzung bei geringeren Kosten und weniger Manpower

In welchen Bereichen DevOps Sinn macht

Trotz der vielen Vorteile darf DevOps nicht als Allheilmittel gesehen werden. Wie bei allen IT-Projekten sollte bei Devops am Anfang die Analyse stehen: In welchen Umgebungen ergibt DevOps grundsätzlich Sinn, in welchen nicht? Für eine extrem sicherheitskritische Transaktionssoftware eignet sich DevOps eher weniger, für mobile Apps hingegen passt es hervorragend. Naturgemäß funktioniert DevOps am besten bei allem, was irgendwie auf einer Private oder Public Cloud laufen kann. Bei all dem darf natürlich das Thema Return on Investment nicht komplett aus den Augen verloren werden. Unsere Projekte zeigen, dass der ROI bei innovativen Anwendungen wesentlich größer ausfällt als bei existierenden Anwendungen.

Die Zukunft gehört DevOps

Im Vergleich zu vielen anderen Ländern waren die deutschen Banken in der Vergangenheit eher träge, was die durchgehende Digitalisierung ihrer Prozesse und die Einführung smarter Kundentools anging. Das lag jedoch nicht an mangelnder Innovationsfreude, sondern vor allem an der extrem strengen Regulierung. Aber die Situation hat sich gewandelt – Gründe dafür sind der gestiegene Wettbewerbsdruck und die Möglichkeiten, die Cloud Computing und der DevOps-Ansatz bieten. Mittlerweile gibt es sehr gute Möglichkeiten, neue Anwendungen für den Bankensektor zu entwickeln und mit Internetfirmen auf Augenhöhe zu konkurrieren. Und immer mehr Banken nutzen dafür DevOps, vor allem im Investment Banking und bei Onlineservices.