Bank meets Microservices and DevOps

Die IT im Mittelpunkt von Geschäftsabläufen

Im Zuge der Digitalisierung ist die IT immer weiter in den Mittelpunkt der Geschäftsabläufe gerückt und muss heute sehr hohen Anforderungen an Effektivität und Flexibilität genügen. Banken müssen immer schneller auf neue Nutzergewohnheiten und auf regulatorische Vorgaben – etwa MiFID 2 oder MiFIR − reagieren, welche die IT enorm unter Zeitdruck setzen. Mit klassischer Softwareentwicklung sowie monolithischen Architekturen, wie sie in Banken oft vorzufinden sind, könnt ihr diese Bestrebungen aber kaum erreichen.

In meinem Blog-Beitrag möchte ich euch das Konzept der Microservices vorstellen, denn es versucht diesen neuen Anforderungen gerecht zu werden. Hier werden nämlich Konzepte wie Continuous Delivery oder DevOps unterstützt, fachliche Organisationen gefördert und sie sind gleichzeitig sehr flexibel in der Skalierung von Entwicklung und Betrieb.

Was sind Microservices?

Einen Microservice könnt ihr als Programm innerhalb eines größeren Systems ansehen. Dabei kann jeder Microservice eigenständig betrieben werden und zwar unabhängig davon, welche anderen Microservices in eurem System noch vorhanden sind und welche technische Basis sie haben.

Die Intention dieser Art der Modularisierung ist, dass ein Modul einen bestimmten Zweck innerhalb des Systems erfüllt. Dabei sind die Aufgaben so voneinander abgegrenzt, dass sie bei Änderungen der Funktionalität möglichst geringe Auswirkungen aufeinander haben. Die Kommunikation zwischen den Services erfolgt über definierte Schnittstellen. Damit seid ihr in der Lage, einen Microservice unabhängig von anderen Microservices in Produktion zu bringen. Ein hoher Automatisierungsgrad ist für euch so erreichbar und ihr könnt neue Releases mit den entsprechenden Features schneller in Produktion bringen.

Die Größe und Komplexität eines Microservices ist nicht spezifiziert. Jedoch sollte ein Microservice so groß sein, dass jedes eurer Teammitglieder die Funktionsweise vollumfänglich verstehen kann. Zusätzlich sollte euer verantwortliches agiles Entwicklungsteam in der Lage sein, einen Service innerhalb weniger Wochen komplett neu zu entwickeln, wenn es aus fachlichen oder technischen Gründen notwendig ist.

Welche Auswirkungen haben Microservices auf die Organisation?

Microservices erlauben es, die Systemarchitektur an die Fachlichkeit der Bank auszurichten und jeweils eurem agilen Team die Verantwortung für eine Fachlichkeit zu übertragen. So kann ein Microservice zum Beispiel einen Buchungsvorgang, die Registrierung oder die Rechnungserstellung umfassen. Ein Microservice sollte jedoch nicht mehrere domänenübergreifende Funktionen abdecken, sondern domänenspezifisch entworfen werden. Mithilfe dieser Architektur könnt ihr Abstimmungsaufwände vermindern und die Selbstorganisation eures Teams fördern. Jedes eurer Teams kann unabhängig neue Features entwickeln und eigene geschäftliche Ziele verfolgen. Die Eigenständigkeit und die einfache Ersetzbarkeit von Microservices reduzieren die Kosten von Fehlentscheidungen und ermöglichen es euch, schneller auf äußere Einflüsse zu reagieren.

Eine Koordination von Release-Terminen oder Testphasen zwischen euren Teams ist nicht notwendig, da die Entwicklungsgeschwindigkeit in der Verantwortung eurer jeweiligen Teams liegt. Die Verzögerung eines Teams wirkt sich nicht auf die anderen aus. Projekte, die nur einen bestimmten Microservice betreffen, haben den Vorteil, dass ihr Budgets und Zeitrahmen genauer einschätzen und eine deutlich bessere Planbarkeit erzielen könnt. Im Falle eines Zeit- und/oder Budgetproblems bleiben die Auswirkungen innerhalb dieser Systemgrenzen.

Hierbei solltet ihr beachten, dass Microservices die Anzahl der Fehlerquellen erhöhen. Aus diesem Grund ist es wichtig, dass ihr Microservices mit einer möglichst hohen fachlichen Bindung entwickelt, damit ihr Fehler auf ein Minimum senken könnt. In der Konsequenz hat die Architektur bei Microservices einen entscheidenden Stellenwert und Defizite im Rahmen der Architekturarbeit können durch Technologie nicht beglichen werden.

Von der Entwicklung in den Betrieb

Banken orientieren sich typischerweise an fest vorgegebenen Release-Zyklen und am Wasserfallmodell. Jede Phase hat in einem Wasserfallmodell vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen, die durch entspreche Quality Gates abgesichert werden. Auf diese Weise erreicht ihr ein hohes Maß an Softwarequalität, die mit den Qualitätsstandards der Bank konform ist. Dieses Vorgehen hat jedoch den Nachteil, dass eine Bank nicht flexibel auf neue Anforderungen reagieren kann.

Somit erfordert die Architektur der Microservices, dass euer agiles Team den Betrieb der Microservices gewährleisten muss, um reaktionsfähiger zu sein. Mit einem Ansatz wie DevOps führt ihr das agile Prinzip auf nachgelagerte Prozesse − wie beispielsweise die Bereitstellung und der Betrieb von Software – fort. Sie gelten als letzter Baustein für eine reaktionsfähige IT im digitalen Zeitalter.

Dabei bezeichnet DevOps den Zusammenschluss von Entwicklung und IT-Betrieb. Das zentrale Merkmal dieses Prinzips ist, dass eure Entwicklungs- und IT-Teams nicht mehr isoliert voneinander arbeiten, sondern zusammen. Das Ziel, sowohl die Produktivität als auch die Zuverlässigkeit der betrieblichen Abläufe zu optimieren, steht im Vordergrund. Der Widerspruch soll durch Kollaboration und Vermengung der Kompetenzen beider Seiten aufgelöst werden. Eure Teams, die nach DevOps ausgerichtet sind, können nicht nur die Entwicklung, sondern auch den Betrieb der Microservices verantworten. Dadurch wird die Kommunikation zwischen beiden Lagern deutlich einfacher. Mit Unterstützung von Continuous Delivery könnt ihr Änderungen nach umfangreicher Qualitätsprüfung zügig in Produktion bringen.

Fazit: Agile Methoden für raschere Anpassungen

Banken können mithilfe von agilen Methoden wie Scrum und Microservices besser auf neue Anforderungen in einem schwierigen Marktumfeld reagieren und Innovationen schneller realisieren. Sehr wichtig ist dabei die enge Verzahnung zwischen Entwicklung und IT-Betrieb mittels DevOps. Kleine Teams können individuelle Dienste entwickeln, testen und in Produktion bringen. Auf diese Weise ergänzen sich Microservices und DevOps gegenseitig. Zum einen könnt ihr eine flexiblere und effizientere Systemlandschaft realisieren, zum anderen Prozesse etablieren, mit denen diese Anwendungen schnell und mit hoher Qualität entwickelt und bereitgestellt werden können. Die Betrachtung der Organisation als Teil der Architektur ist jedoch eine zentrale Herausforderung, vor der Banken im Moment stehen. Über Jahre hinweg haben die Zentralisierung und die Orientierung an der Schichtenarchitektur auch die Organisationeinheiten eines Unternehmens abgebildet. Um Microservices und DevOps in einer Bank zu etablieren, müssen sich Banken längerfristig auf eine Umstrukturierung der Organisation einstellen. Wenn die Organisation ein solches Denken noch nicht unterstützt, könnt ihr mit dem Einsatz einer Microservice-Architektur Schaden anrichten, weil Reibungspunkte zwischen Abteilungen sich vervielfachen können.

Dieser Beitrag ist auch im „Der Bank Blog“ erschienen.