Teil 2: Architekturelle Schnitte für Integrationsplattformen

Einleitung

Im ersten Teil des Artikels haben wir die Notwendigkeit zur fachlichen Integration aller in die Abwicklung der Gesamtbanksteuerung (GBS) involvierten Geschäftsobjekte motiviert. Diese Integrationsleistung wird typischerweise durch Integrationsplattformen erbracht, die auch im Kern des zweiten Teils dieses Artikels stehen. Integrationsplattformen sind komplexe IT-Systeme, deren Hauptaufgaben die Verknüpfung der angeschlossenen Systeme sowie die fachliche Integration, Aufbewahrung und das Zur-Verfügung-Stellen der ausgetauschten Daten sind. Nachdem wir im ersten Teil des Artikels fachliche Anforderungen und Komplexitätstreiber einer solchen Plattform vorgestellt haben konzentrieren wir uns im zweiten Teil auf das Vorstellen und Bewerten unterschiedlicher architektureller Schnitte, die mögliche Optionen für den Aufbau einer Integrationsplattform darstellen.

Moderne Softwareentwicklung

Vielen Unternehmen stellt sich die Frage, wie sie die Leistungsfähigkeit ihrer Software-Entwicklung messen können. In den letzten Jahren haben sich hierfür als Key Performance Indicators (KPIs) die folgenden vier Metriken etabliert:

• Deployment Frequency: Wie oft werden Änderungen produktiv ausgerollt? (von „mehrmals am Tag“ bis „alle X Monate“)

• Lead-Time-for-Changes: Wie lange dauert es vom Fertigstellen des Codes bis zum produktiven Ausrollen? (von „weniger als einen Tag“ bis „mehrere Monate“)

• Mean-Time-to-Recover: Wie lang dauert es nach einem Fehler in Produktion den üblichen Betrieb wieder herzustellen? (von „weniger als eine Stunde“ bis „mehr als eine Woche“ )

• Change-Failure-Rate: Welcher Anteil aller Änderungen führt zu Problemen in Produktion? (von < 5% zu > 50 %)

Banken scheitern oft daran, ihre Integrationsplattformen so aufzustellen, dass sie in diesen Metriken ausreichend gute Ergebnisse erzielen. Zum einen liegt dies an den im ersten Teil beschriebenen Komplexitätstreibern, zum anderen aber oft auch an veralteter Technologie und an fehlenden Verständnis für moderne Entwicklungsprozesse und Qualitätssicherungsstrategien. Eine zwingende Kern-Voraussetzung für ein gutes Abschneiden in allen vier KPIs ist ein hoher Automatisierungsgrad und eine hohe Testabdeckung durch Unit- und Integrations-Tests. Diese Anstrengungen werden oft unter dem Begriff Continuous Integration / Continuous Delivery (CI/CD) zusammengefasst (vgl. https://www.redhat.com/en/topics/devops/what-is-ci-cd ). Beim Design einer neuen Integrationslösung ist es daher von höchster Wichtigkeit darauf zu achten, dass die Architektur durch ihren Schnitt als auch durch ihren technologischen Unterbau es möglichst einfach macht, die Entwicklungsprozesse und vor allem das Testen der erstellten Lösung soweit wie möglich zu automatisieren.

Architektureller Schnitt von Integrationsplattformen

In diesem Abschnitt stellen wir die gängigsten Möglichkeiten zum Schnitt einer Integrationsarchitektur vor. Dazu nennen wir ihre wesentlichen Eigenschaften sowie ihre Vor- und Nachteile und skizzieren, unter welchen Bedingungen eine Architektur am sinnvollsten eingesetzt werden kann.

Für die Wahl eines Architekturschnitts spielen neben der Projekt- oder Unternehmens-Organisation auch kulturelle Voraussetzungen und die Fachlichkeit des Unternehmens eine wichtige Rolle. Diese Faktoren müssen daher die bereits beim Design der Architektur bedacht werden. Ein hoher Automatisierungsgrad setzt z.B. eine Firmenkultur voraus, welche die IT als wesentlichen Treiber des Geschäfts und damit als wesentlichen Faktor für den langfristigen Unternehmenserfolg versteht.

Noch weit vor anderen Entscheidungen, wie etwa der Wahl der konkret einzusetzenden Technologien, ist die Definition eines passenden architekturellen Schnitts eine strategische, langfristige und nur schwer zu ändernde Grundlage, die langfristig große Auswirkung auf Erfolg- oder Misserfolg des ganzen Vorhabens haben kann. Daher ist diese Entscheidung sorgfältig zu treffen: ein späterer Wechsel ist meist nicht mehr möglich oder zumindest mit hohen Aufwänden verbunden.

Abbildung 1: DWH Monolith

Einer der größten Vorteile einer monolithischen Architektur ist die zentralisierte Core-Schicht: Sie stellt als Single-Source-of-Truth eine vollständig konsistente und global einheitliche Sicht auf den gesamten Datenbestand der Bank, aus der sich alle Abnehmersysteme bedienen. Dazu können Data Governance-Anforderungen wie BCBS 239 zentral gelöst werden, was es deutlich erleichtert einen konsistenten Data Catalog und eine saubere Data Lineage anzubieten, die alle Datenflüsse Front-to-Back auf Feldebene abbildet. Implementiert wird ein solches System oft mit proprietären ETL-Werkzeugen (Extract-Transform-Load) – möglich sind aber natürlich eine große Reihe verschiedener anderer Technologien.

Die Zentralisierung ist gleichzeitig aber auch die größte Schwäche dieses Ansatzes: da alle Transformationen im gleichen Repository zusammenkommen wächst mit jeder Änderung die Gefahr von unvorhergesehenen Wechselwirkungen zunehmend, wodurch die Aufwände für Test und Wartung steigen. Diese Probleme manifestieren sich umso mehr, je niedriger der Automatisierungsgrad und Testabdeckung sind. Insbesondere im Umfeld vieler proprietärer ETL-Werkzeuge sind Aspekte wie Unit-Testing im Speziellen und CI/CD im Allgemeinen wenig verbreitet, was zu enormen Problemen beim Test und der Qualitätssicherung führen kann.

Die organisatorische Zentralisierung kann sich potentiell aber als noch schwerwiegender als die technische auswirken, zwingt sie doch alle Anforderer dazu, umzusetzende Transformationen bei der Integrationsplattform zu bestellen, anstatt sie selbst implementieren zu können: zu groß wäre nicht nur die Gefahr, fremde Artefakte ungewollt anzupassen, sondern auch der Aufwand fremde Teammitglieder für eine kurze Zeit in alle Prozesse des zentralen Integrationsteams einzuführen. Dadurch sind Anforderer auf Gedeih und Verderb den Release-Zyklen und der Priorisierung des Integrationsteams ausgeliefert. Insbesondere für zeitkritische Anforderungen stellt dies oft ein eklatantes Problem dar, welches direkt die Fähigkeit der Bank einschränkt, auf Änderungen am Markt schnell zu reagieren. Noch dazu steigt mit der Größe der monolithischen Integrationsplattform die Chance, dass sie die Entwickler des Integrationsteams durch zeitgleich konkurrierende Umsetzungen gegenseitig behindern.

Die erwähnten Nachteile zeigen sich oft in den folgenden Symptomen:

• Die Entwicklung neuer Features dauert lange und ist teuer (besonders bei geringem Automatisierungsgrad und schlechter Testabdeckung)

• Anforderungen müssen mit großem Vorlauf angemeldet spezifiziert werden; Fach-Spezifikationen sind Gegenstand langer Debatten, da sie die Aufgaben zwischen unterschiedlichen Teams abgrenzen.

• Integrationstests verursachen hohe Aufwände

• Die Leistungsfähigkeit des Teams skaliert schlecht mit seiner Größe

• Features können nicht in kleinen Inkrementen geliefert werden. Dies kann zu sehr langen Release-Zyklen führen, was dem Gedanken der zeit- und marktnahen Entwicklung entgegensteht.

Die Probleme mit dieser Architektur wiegen im Vergleich zu deren Vorteilen umso schwerer, je komplizierter die fachliche Integrationsleistung ist, sowohl in Breite als auch in Tiefe. Ab einer bestimmten Größe und technischer Komplexität raten wir daher von einem monolithischen Ansatz ab.

Ist jedoch die fachliche Komplexität beschränkt und wird ein moderner Entwicklungsprozess mit modernem Technologie Stack verwendet, kann sich eine monolithische Architektur durchaus als vorteilhaft gegenüber anderen hier vorgestellten architekturellen Schnitten erweisen: er vermeidet nicht nur organisatorische und technologische Komplexität, sondern erleichtert dabei auch drastisch die Data Governance. Systematische Nachteile, wie etwa organisatorische Abhängigkeiten und die Qualitätssicherung treten mitunter dabei kaum zu Tage, wenn aufgrund begrenzter fachlicher Komplexität und modernen Entwicklungsprozessen ohnehin in kurzen Intervallen Software ausgeliefert werden kann.

Data Lake

Abbildung 2: Data Lake

Ein weiterer populärer Ansatz ist der des Data Lake. Im Gegensatz zum DWH-Monolithen werden die Daten hier nicht fachlich integriert, sondern werden größtenteils unverändert direkt in einem zentralen Datenspeicher abgelegt. Hierdurch ist das Aufnehmen neuer Daten sehr günstig, da die Daten nicht von vorneherein inhaltlich analysiert und keine Transformationsstrecken implementiert werden müssen. Die Arbeit der Integration und der Aufbereitung wird stattdessen in die Auslesevorgänge verlagert, die sich mit mächtigen Analysewerkzeugen Ergebnisse aus den bereits verfügbaren Daten selbst ableiten. Dabei wird jeder Ausleitungs- oder Analyseadapter typischerweise nicht nur technisch, sondern auch organisatorisch strikt von den anderen getrennt (siehe Abbildung 2: Data Lake). Dadurch kann (im Unterschied etwa zum monolithischen Ansatz) bei diesem Vorgehen jeder Adapter unabhängig voneinander entwickelt und auch veröffentlicht werden. Gleichzeitig wird damit auch ein großes Maß an Flexibilität bewahrt, da jeder Adapter potentiell sehr einfach auf alle Daten zugreifen kann. Einer der größten Vorteile dieses Vorgehens ist eine deutliche Verringerung der Lead-Time-for-Changes, d.h. der Zeit die von der Konzeption eines Features bis zu ihrem Go-Live vergeht. Der Hauptgrund hierfür ist die organisatorische Unabhängigkeit der Adapter Teams im Abnehmerschnitt, die sich für die Umsetzung kaum mit anderen Teams abstimmen oder beeinflussen lassen müssen. Zwar müssen sie alle fachlichen Transformationsschritte selbst implementieren (im Gegensatz etwa zum monolithischen Ansatz), dieser Nachteil wird aber durch seine Unabhängigkeit für sie mehr als aufgewogen: Daten stehen in der Regel sehr schnell und unbürokratisch zur Verfügung. Das größte Problem dieses Schnitts ist dagegen die fehlende Konsistenz zwischen den einzelnen Abnehmer-Adaptern: Da jeder von ihnen alle fachlichen Transformationsschritte (bspw. Fachfunktionen für Kennzahlen) selbst implementiert, ist die Wahrscheinlichkeit hoch, dass es zu Abweichungen und damit zu Konsistenzproblemen zwischen den erstellten Ergebnissen kommen kann. In einem komplexen und fachlich stark verwobenen System wie einer Bank, kann dies schwere Auswirkungen haben. Auch die Einhaltung der Data Governance gestaltet sich schwieriger als in einem Monolithen, sofern man die Unabhängigkeit der Adapter-Teams und die Vorteile des einfachen Datenzugriffs nicht zu sehr einschränken möchte. Dazu kommt, dass es auch beim Data-Lake Schnitt schwer ist zwischen der Datenhaltung und den Adaptern eng abgegrenzte Schnittstellen zu definieren, was das Testen und die inhaltliche Analyse deutlich erschweren kann. Durch fehlende Ownership für die Eingangsdaten werden zudem zuliefernde Systeme aus ihrer Verantwortung entlassen, Änderungen zu kommunizieren oder über Auswirkungen der Änderungen Bescheid zu wissen, mit potentiell katastrophalen Folgen für den kompletten Datenhaushalt. Aufgrund der Wichtigkeit der Data Governance im GBS-Umfeld folgen GBS-Integrationslösungen daher nur selten dieser Architektur. Immer dann, wenn mögliche Konsistenzprobleme und die Data Governance eine untergeordnete Rolle spielen – beispielsweise als Basis für das interne Reporting – kann der Data Lake dagegen seine Vorteile voll ausspielen. Folgende Nachteile gehen häufig mit dieser Architektur einher:

• Es kommt leicht zu Konsistenzproblemen zwischen den Ergebnissen unterschiedlicher Adapter.

• Allgemein sind Data Governance-Anforderungen schwer umzusetzen.

• Es besteht die Gefahr, dass sich der Lake bei wachsender Komplexität, fehlender fachlicher Transparenz und schlechter Testabdeckung zu einer Sammlung schwer anpassbarer Monolithen entwickelt.

• Sollen Adapter-übergreifende Integrationsaufgaben zentral gelöst werden, um Konsistenz- oder Redundanzprobleme zu vermeiden, gehen einige der Vorteile des Schnitts aufgrund der neuen Abhängigkeiten teilweise verloren.

Abschließend kann man zusammenfassen, dass es sich beim Data Lake um einen Ansatz aus der Produktentwicklung handelt, der zum Ziel hat, möglichst schnell und unkompliziert analytische Daten aus einer großen Menge von Informationen generieren zu können. Im GBS-Kontext geht es jedoch häufig um für die Bank kritische und gleichzeitig auch rechtlich bindende Meldungen, die Erfüllung von BCBS-239 und anderen Regularien, weswegen wir für dieses Umfeld den Einsatz alternativer Ansätze empfehlen, die ein höheres Augenmerk auf fachliche Transparenz und Vereinheitlichung legen.

Addendum: Data Lakehouse

Der Data Lake Ansatz wird mittlerweile erweitert um den Begriff des Data Lakehouse oder einfach nur Lakehouse. Das Data Lakehouse versucht hierbei ein “Best-of-Both-Worlds” aus Simplizität bei der Datenbereitstellung und der Governance-Fähigkeiten des klassischen Data-Warehouse in einem Ansatz zu vereinen. Ein Data Lakehouse zeichnet sich dadurch aus, dass es zum einen in der Cloud aufgebaut ist, ähnlich wie ein Data Lake unstrukturierte und strukturierte Daten annehmen und verwalten kann aber als grundsätzliches Prinzip versucht, die Data Governance von Anfang an mit zu betrachten. Als Anbieter auf dem Markt sind derzeit etwa Snowflake und Databricks mit eigenen Software-as-a-Service (SaaS) -Plattformen zu nennen. Mit Einschränkungen beim Support der Data Governance können auch mit AWS Redshift oder vergleichbaren Systemen der Google Cloud Platform solche Lösungen erschaffen werden. Mit der Weiterentwicklung von Technologien wie z.B. Parquet und den Möglichkeiten großer Cloud Plattformen diverse Datentöpfe und technische Formate zu vereinen, ist diese Architektur eine moderne Interpretation des Data Lake Ansatzes. Weitere Charakteristiken wie der inhärent Cloud-native Aufbau, Sprachen- und Toolagnostik bei der Abfrage und beim Speichern von Daten, Streaming-Fähigkeit, Trennung von Lese- und Schreibzugriff und Tools zur Unterstützung des Metadatenmanagements lassen diesen Ansatz passend für die Lösung der Probleme in Data-Lake oder Data Warehouse Architekturen erscheinen. Am Markt können im Moment nur wenige Anbieter ein umfassendes, vollständig integriertes Baukastensystem für diesen Use-Case anbieten. Dies erhöht für potentielle Anwender dieses Ansatzes das Risiko eines Vendor Lock-ins. Weiterhin ist das Metadaten-Management meist an proprietäre Werkzeuge gebunden, die erst erlernt werden müssen. Ein weiterer Nachteil ist, dass ein Data Lakehouse im Grunde dann doch monolithisch angelegt ist und ein großes Softwareartefakt auf einer Cloud Plattform darstellt. Ob und wie schwer dieser Nachteil wirklich wiegt, kann erst in der Zukunft bewertet werden, wenn diese Art von Plattformen auch in der Breite genutzt werden. Obwohl das Data Lakehouse also mehr technische Möglichkeiten bei der Data Governance bietet und ein Framework verspricht, was trotz leichtgewichtiger Datenbehandlung auch die notwendigen Formalitäten einhalten soll, müssen sich diese beworbenen Vorteile erst als sinnvoll erweisen.

Verteilte Architektur (Data Mesh)

Abbildung 3: Verteilte Architektur

Eine Integrationsarchitektur kann auch auf Basis eines dezentralen, lose gekoppelten Systems aufgebaut werden. Dieses Architektur-Prinzip ist in den letzten Jahren vor allem durch das Data Mesh Paradigma populär geworden, das folgende vier Prinzipien als die Basis seiner Architektur definiert: Domain Ownership, Data as a Product, Self-Service Data Platform, und Federated Governance

1. Domain Ownership: Die Gesamtheit der Organisation ist organisiert in überlappungsfreie Einheiten, die jeweils einen Teil der Gesamtfachlichkeit verantworten. Im Allgemeinen werden diese Einheiten Domänen oder Domains genannt gemäß dem Paradigma des Domain Driven Design. Die Domänen-Teams sind cross-funktional aufgestellt und verantworten neben der organisatorischen Fachlichkeit im Kontext von Data Mesh ebenfalls deren Daten. Obwohl das Finden eines geeigneten Domänenschnitts einen hohen Aufwand erzeugen kann, hat die organisatorischen Trennung einige Vorteile, wie z.B. die dadurch entstehenden kleinen, leichtgewichtigen und spezialisierten Teams, die sich spezifisch um einen ihnen zugeteilten Ausschnitt kümmern und unabhängig entwickeln können.
2. Data as a Product: Daten werden von den jeweiligen Domänen-Teams aufbereitet und als Produkt bereit gestellt. Zentral ist der Gedanke, dass das Produkt Abnehmer sucht und damit Daten-Silos in den einzelnen Domänen aufgebrochen und aktiv vermieden werden. Konsequenterweise werden die Datenprodukte zum Konsum bereitgestellt. Es entsteht eine Kultur der direkten Verantwortung für die Bereitstellung von Daten, die transparent angeboten und für andere Teams einfach zu konsumieren sind.
3. Self-Serve Data Platform: Um die Entwicklung von Datenprodukten möglichst weit zu vereinfachen, stellt ein Plattform-Team eine technische Plattform zur Verfügung, die es erlaubt Datenobjekte einfach zu serialisieren und wieder abzurufen. Dies ermöglicht den Domänen-Teams sich selbst, d.h. ohne Hilfe des Plattform-Teams, an der unterliegenden Datenhaltung zu bedienen. Neben der Vereinfachung der Entwicklung wird so insbesondere auch die Datenhaltung über Domänengrenzen hinweg vereinheitlicht. Insbesondere dieses Prinzip spielt im Zusammenspiel mit der Governance eine zentrale Rolle im Kontext GBS.
4. Federated Governance: Das Prinzip der Federated Governance beschreibt die Anforderung, die Data Governance auch in einem verteilten System zu lösen. Dazu muss die Data Governance Domänen-übergreifend betrachtet werden, d.h. über inner-organisatorische Grenzen hinweg. Dieser Ansatz ähnelt dem Konzept der Gilden in Organisationsstrukturen – allerdings muss für die Einhaltung der BCBS-Anforderungen garantiert werden können, dass solche übergreifenden Data Governance Standards auch global eingehalten werden. Dies in einem verteilten System zu bewerkstelligen ist eine deutliche Verschärfung des Problems im Vergleich zu zentralistischen Ansätzen.

Speziell der organisatorische Aspekt dieses Architekturpatterns (siehe Abbildung 3: Verteilte Architektur) spielt eine große Rolle bei der Optimierung der DevOps-KPIs. Obwohl ein gewisser Abstimmungsaufwand bei der Koordination der Schnittstellen verbleibt, wirken sich die Vorteile dieses Schnitts insgesamt positiv auf die Lead-Time und Deployment-Frequency aus. Alle entwickelnden Teams haben die Möglichkeiten mit geringem Aufwand ihre Schnittstellen zu testen und nach Erfüllung aller Qualitätskriterien selbstständig auszurollen. So sind Änderungen im Code mit hoher Frequenz, niedriger Komplexität und gesteigerter Konfidenz möglich. Architekturen mit weniger eng umgrenzten Schnittstellen können das in dieser Form nicht leisten.

In seiner ursprünglichen Ausprägung konzentriert sich das Data Mesh Paradigma sehr auf die Anforderungen analytischer oder operativer Fragestellungen im Bereich der Datenanalyse und hat daher für einige typische Probleme der Datenintegration im GBS-Umfeld keine einfache Lösung parat. Insbesondere sind im GBS-Umfeld die operativen, bestandsführenden Systeme in der Regel nicht selbst Bestandteil der GBS-Integrationslösung, wodurch sie als Folge nicht Teil der Domänen sein können. Dies widerspricht in gewisser Hinsicht dem im Data-Mesh üblichen Konzept der Datenprodukte. Weiterhin ist die Umsetzung einer klassischen Self-Service Strategie wie bei Data Mesh anders umzusetzen als z.B. im Bereich des Reporting eines Produktherstellers: Die Self-Service Strategie hilft vor allem bei der experimentellen Data Discovery und unterstützt beim schnellen Umsetzen, was den Notwendigkeiten einer an regulatorischen Anforderungen ausgerichteten Bankenwelt entgegensteht. Daher kann das Data Mesh Paradigma nicht vollständig auf den hier besprochenen Kontext angewandt werden. Mit einer stärkeren Betonung der Säulen “Federated Governance” und “Domain Ownership” funktioniert dies aber dennoch.

In Bezug auf die Anwendung des Data Mesh Prinzips auf den GBS-Kontext stellen sich dem verantwortlichen Architekten direkt eine Reihe zentraler Fragen, von denen wir eine Auswahl der wichtigsten im Folgenden vorstellen wollen.

• Domänenschnitt:

Grundsätzlich konkurrieren im GBS-Bereich zwei orthogonale Sichten um den Schnitt der Domänen: der Produktschnitt, der hauptsächlich vom Geschäftsmodell der Bank definiert wird, und der Abnehmerschnitt, der sich nach den Anforderungen der GBS-Funktionen (z.B. Meldewesen, Rechnungswesen) richtet. Oft ist es zielführend das Datenmodell quell-naher Domänen nach Produkten und verwendungs-naher Systeme nach Abnehmern zu schneiden. Spielraum verbleibt in Zentrum der Integration, in dem zum Einen die eigentliche fachliche Integration stattfindet und zum Anderen Rechenkerne mit Informationen beliefert werden, aus denen Kennzahlen errechnet werden. Falls nicht durch andere Faktoren vorgegeben, ist es sinnvoll, bei der Wahl der Domänen dem Verlauf des Abschlussprozesses der Bank zu folgen. Auf diese Weise ist es in der Praxis möglich ein fachlich verständliches und langfristig wartbares Domänenmodell zu entwickeln. Stückweise kann es aber sinnvoll sein für zentrale, querliegende Aspekte (z.B. Buchungen) einzelne zusätzliche Domänen zu schaffen, um Redundanzen zu vermeiden.

• Persistenz:

Der Austausch von Informationen zwischen den einzelnen Domänen geschieht in modernen verteilten Systemen oft über Events, die atomare Zustandsänderungen im modellierten Geschäftskontext repräsentieren, z.B. die Adressänderung eines Kunden. Für die dauerhafte Persistenz der so ausgetauschten Daten bieten sich vor allem zwei Möglichkeiten an:

a. Die Speicherung ausschließlich des Ergebnisses der ausgetauschten Events zu bestimmten Zeitpunkten – beispielsweise durch fortwährende Speicherung jedes Kunden in einer Datenbank inklusive seiner Adresse, ausschließlich zum aktuellen Zeitpunkt und zum Jahresbeginn.

b. Die Speicherung der ausgetauschten Events selbst, wobei bei konkreten Anfragen an die Integrationsplattform die gespeicherten Events direkt beim Zugriff abgespielt werden müssen, um z.B. die aktuelle Adresse eines Kunden zu errechnen („Event Sourcing“).

Beide Ansätze besitzen eigene Vor- und Nachteile, die für jede Architektur getrennt zu evaluieren sind. So besitzt der erste Ansatz etwa den Vorteil, dass die Daten schon beim Zugriff vollständig aggregiert vorliegen, während im zweiten Ansatz Events eventuell direkt vor dem Zugriff noch aggregiert werden müssen, was je nach Use Case die Latenz erhöhen kann. Dagegen hat Event Sourcing unter anderem den Vorteil, dass keine gegebenenfalls aufwändigen Datenbank Migrationen bei Erweiterung des Datenmodells durchgeführt werden müssen.

• Governance:

Die Umsetzung der Governance ist in einem derartig verteilten System kein einfach zu lösendes Thema. Durch die organisatorische Unabhängigkeit der Systeme und dem generellen Versprechen, dass jede Domäne selbst für ihr Innenleben verantwortlich ist, gibt es zunächst keinen zentralen Punkt, dem man die Umsetzung der Data Governance Anforderungen auferlegen könnte. Dieses Problem wird noch schwerer zu lösen, wenn man bedenkt, dass BCBS-Anforderungen eine Front-to-Back Lineage für alle wichtigen Kennzahlen auf Feldebene fordern. Es ist also notwendig, über Domänengrenzen hinweg aufzeigen zu können, wie eine konkrete Kennzahl tatsächlich berechnet wurde. So werden Domänen faktisch zur Whitebox, d.h. ihr Innenleben wird nach außen gekehrt.

Um diesen Anforderungen domänenübergreifend entsprechen zu können, ist es nötig, die Autonomie der Domänen zu beschränken. Beispielshalber ist es möglich sich Domänen-übergreifend auf einheitliche Werkzeuge zu einigen, die durch Bibliotheken, eine Domänen-spezifische Sprache und/oder statische Codeanalyse garantieren, dass jede Domäne ihre Lineage an zentraler Stelle offenlegt. Alternativ ist es möglich den Domänen aufzuerlegen, ihre Metadaten durch Aufruf eines externen Services zentral zu melden. Um ein Skalieren des Gesamtsystem zu ermöglichen und aufsichtsrechtliche Prüfungen zu erleichtern, sollte ein Verfahren gewählt werden, das die Einhaltung der Governance-Anforderungen auch in einem verteilten System garantiert und nicht nur ermöglicht. Eine Data Governance-as-Code Lösung (siehe Abbildung 3: Verteilte Architektur), die alle Teams einbezieht und gemeinsame Standards schafft, kann hier z.B. ein guter Lösungsansatz sein. Auch hier ist die Autonomie der Domänen eingeschränkt.

Die Implementierung einer GBS-Integrationsplattform als Data Mesh ist nicht trivial und stellt Anforderungen an die Bank als Organisation und deren Kultur. Die cross-funktionalen Teams, insbesondere deren technisch ausgerichtete Teile, müssen einen hohen Ausbildungsgrad besitzen und Probleme autonom und eigenverantwortlich lösen können. Sind diese Voraussetzungen gegeben, lohnt sich eine solche verteilte Architektur vor allem dann, wenn die Bank ein hohes Maß an fachlicher Komplexität und ein umfangreiches fachliches Modell besitzt. Eine Data Mesh-ähnliche Architektur lockt dann mit Vorteilen wie erhöhter Entwicklungsgeschwindigkeit sowie erleichterter Handhabung und Erweiterbarkeit der fachlichen Komplexität, die sonst allzu schnell in einen nicht mehr wartbaren und schwerfälligen Monolithen mutieren könnte.

Fazit

Der Aufbau einer für das konkrete Unternehmen passenden Integrationsarchitektur ist kein triviales Problem, insbesondere nicht im Bereich der Banksteuerung, in dem aufsichtsrechtliche Anforderungen, hohe fachliche Komplexität und große, heterogene IT-Landschaften aufeinandertreffen. Anders als im Nicht-Banken-Bereich ist es hier oft schwer die Produkt- und (Bank-)Steuerungssicht untereinander zu priorisieren. Typischerweise ist beiden in ähnlicher Priorität Rechnung zu tragen, und das unter Aufrechterhaltung eines hohen Qualitätsstandards an die Data Governance. Eine klassische Trennung in analytische und operative Datenverarbeitung ist weiterhin meist nur schwer vorzunehmen.

Ist die Komplexität der Fachlichkeit nicht zu hoch kann eine monolithische Architektur sich als eine gute Wahl für eine solche Integrationsplattform erweisen. Nicht nur erzeugt sie geringeren organisatorischen Overhead, sondern erleichtert vor allem auch die Einhaltung typischer Data Governance Anforderungen ungemein, da diese Anforderungen an einer Stelle zentral gelöst werden können. Auch erfordert sie ein geringeres Maß an Eigenverantwortung von den Entwicklern, was in Teams mit geringer Erfahrung mit verteilten Systemen ein großer Vorteil sein kann. Voraussetzung für das Gelingen eines solchen Projekts ist allerdings ein moderner IT-Stack, ein hoch-automatisierter Entwicklungsprozess und die Sicherheit, dass sich die Komplexität der zu integrierenden Fachlichkeit in den nächsten Jahren nicht explosionsartig erhöhen wird. Ansonsten wird ein solcher Monolith nicht auf Dauer mit seinen Anforderungen skalieren können.

Ab einer bestimmten fachlichen Komplexität rücken die Vorteile einer verteilten Architektur mehr in den Vordergrund, versprechen sie doch eine deutlich bessere technische und organisatorische Skalierung. Wir empfehlen dabei die Befolgung einiger der Prinzipien des Data Mesh Paradigmas, auch wenn es nicht 1-zu-1 auf den Banksteuerungskontext angewendet werden kann. Bei der Wahl des Schnitts der Domänen sollten Produkt- und Banksteuerungssicht kombiniert werden, mit höheren Freiheitsgraden im Herzen der Integrationslösung, das den GBS-Abschlussprozess modelliert. Die Einhaltung der Data Governance und insbesondere der Front-to-Back Lineage stellt eine solche verteilte Architektur vor deutliche größere Herausforderungen als ein einfacher Monolith. Typischerweise wird es nötig sein, die organisatorische Unabhängigkeit der einzelnen Domänen teilweise einzuschränken, um diese aufsichtsrechtlichen Anforderungen Domänen-übergreifend garantieren zu können. Auf lange Sicht ist eine solche Architektur aber zukunftsfähiger und deutlich besser skalierbar als ein Monolith.